{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"MSYS2 Software Distribution and Building Platform for Windows MSYS2 is a collection of tools and libraries providing you with an easy-to-use environment for building, installing and running native Windows software. It consists of a command line terminal called mintty , bash, version control systems like git and subversion, tools like tar and awk and even build systems like autotools, all based on a modified version of Cygwin . Despite some of these central parts being based on Cygwin, the main focus of MSYS2 is to provide a build environment for native Windows software and the Cygwin-using parts are kept at a minimum. MSYS2 provides up-to-date native builds for GCC, mingw-w64, CPython, CMake, Meson, OpenSSL, FFmpeg, Rust, Ruby, just to name a few. To provide easy installation of packages and a way to keep them updated it features a package management system called Pacman , which should be familiar to Arch Linux users. It brings many powerful features such as dependency resolution and simple complete system upgrades, as well as straight-forward and reproducible package building. Our package repository contains more than 2000 pre-built packages ready to install. For more details see 'What is MSYS2?' which also compares MSYS2 to other software distributions and development environments like Cygwin , WSL , Chocolatey , Scoop , ... and 'Who Is Using MSYS2?' to see which projects are using MSYS2 and what for. Installation Download the installer: msys2-x86_64-20210725.exe Verify with SHA256 checksum 7e055b71306e64192e2612f959f54ae99a5cf57186206ac702d113ef00ba35c0 or GPG signature by 0xf7a49b0ec . Run the installer. MSYS2 requires 64 bit Windows 7 or newer. Enter your desired Installation Folder (short ASCII-only path on a NTFS volume, no accents, no spaces, no symlinks, no subst or network drives, no FAT). When done, tick Run MSYS2 now . Update the package database and base packages. Unless your setup file is very recent, it will take two steps. First run pacman -Syu : $ pacman -Syu :: Synchronizing package databases... mingw32 805.0 KiB mingw32.sig 438.0 B mingw64 807.9 KiB mingw64.sig 438.0 B msys 289.3 KiB msys.sig 438.0 B :: Starting core system upgrade... warning: terminate other MSYS2 programs before proceeding resolving dependencies... looking for conflicting packages... Packages (6) bash-5.1.004-1 filesystem-2021.01-1 mintty-1~3.4.4-1 msys2-runtime-3.1.7-4 pacman-5.2.2-9 pacman-mirrors-20201208-1 Total Download Size: 11.05 MiB Total Installed Size: 53.92 MiB Net Upgrade Size: -1.24 MiB :: Proceed with installation? [Y/n] :: Retrieving packages... bash-5.1.004-1-x86_64 2.3 MiB filesystem-2021.01-1-any 33.2 KiB mintty-1~3.4.4-1-x86_64 767.2 KiB msys2-runtime-3.1.7-4-x86_64 2.6 MiB pacman-mirrors-20201208-1-any 3.8 KiB pacman-5.2.2-9-x86_64 5.4 MiB (6/6) checking keys in keyring 100% (6/6) checking package integrity 100% (6/6) loading package files 100% (6/6) checking for file conflicts 100% (6/6) checking available disk space 100% :: Processing package changes... (1/6) upgrading bash 100% (2/6) upgrading filesystem 100% (3/6) upgrading mintty 100% (4/6) upgrading msys2-runtime 100% (5/6) upgrading pacman-mirrors 100% (6/6) upgrading pacman 100% :: To complete this update all MSYS2 processes including this terminal will be closed. Confirm to proceed [Y/n] Run \"MSYS2 MSYS\" from Start menu. Update the rest of the base packages with pacman -Su : $ pacman -Su :: Starting core system upgrade... there is nothing to do :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... Packages (20) base-2020.12-1 bsdtar-3.5.0-1 [... more packages listed ...] Total Download Size: 12.82 MiB Total Installed Size: 44.25 MiB Net Upgrade Size: 3.01 MiB :: Proceed with installation? [Y/n] [... downloading and installation continues ...] Now MSYS2 is ready for you. You will probably want to install some tools and the mingw-w64 GCC to start compiling: $ pacman -S --needed base-devel mingw-w64-x86_64-toolchain warning: file-5.39-2 is up to date -- skipping [... more warnings ...] :: There are 48 members in group base-devel: :: Repository msys 1) asciidoc 2) autoconf 3) autoconf2.13 4) autogen [... more packages listed ...] Enter a selection (default=all): :: There are 19 members in group mingw-w64-x86_64-toolchain: :: Repository mingw64 1) mingw-w64-x86_64-binutils 2) mingw-w64-x86_64-crt-git [... more packages listed ...] Enter a selection (default=all): resolving dependencies... looking for conflicting packages... Packages (123) docbook-xml-4.5-2 docbook-xsl-1.79.2-1 [... more packages listed ...] m4-1.4.18-2 make-4.3-1 man-db-2.9.3-1 mingw-w64-x86_64-binutils-2.35.1-3 mingw-w64-x86_64-crt-git-9.0.0.6090.ad98746a-1 mingw-w64-x86_64-gcc-10.2.0-6 mingw-w64-x86_64-gcc-ada-10.2.0-6 mingw-w64-x86_64-gcc-fortran-10.2.0-6 mingw-w64-x86_64-gcc-libgfortran-10.2.0-6 mingw-w64-x86_64-gcc-libs-10.2.0-6 mingw-w64-x86_64-gcc-objc-10.2.0-6 mingw-w64-x86_64-gdb-10.1-2 mingw-w64-x86_64-gdb-multiarch-10.1-2 [... more packages listed ...] Total Download Size: 196.15 MiB Total Installed Size: 1254.96 MiB :: Proceed with installation? [Y/n] [... downloading and installation continues ...] To start building using the mingw-w64 GCC, close this window and run \"MSYS MinGW 64-bit\" from Start menu. Now you can call make or gcc to build software for Windows. Check out the introduction page to learn which Start menu item to use when and which packages to install. Take look at Detailed MSYS2 install guide for troubleshooting and additional details on how to keep your MSYS2 up-to-date. Sponsors Our main server is sponsored by jsdelivr.com Authors and Contributors Alexpux (Alexey Pavlov) martell (Martell Malone) mingwandroid (Ray Donnelly) Elieux (David Macek) lazka (Christoph Reiter) Renato Silva niXman naveen521kk (Naveen M K) Biswa96 (Biswapriyo Nath) jeremyd2019 (Jeremy Drake) mati865 (Mateusz Miku\u0142a) Donations Alexey Pavlov ( @alexpux ) WebMoney transfer to the following WebMoney wallets: E271473533800 R691797957081 Z110171850957 PayPal: alexpux@gmail.com Yandex.Money: 41001429355429 Ray Donnelly ( @mingwandroid ) See https://www.msys2.org/news/#2021-04-21-rip-mingwandroid Christoph Reiter ( @lazka ) GitHub Sponsors: https://github.com/sponsors/lazka PayPal: reiter.christoph@gmail.com","title":"Getting Started"},{"location":"#installation","text":"Download the installer: msys2-x86_64-20210725.exe Verify with SHA256 checksum 7e055b71306e64192e2612f959f54ae99a5cf57186206ac702d113ef00ba35c0 or GPG signature by 0xf7a49b0ec . Run the installer. MSYS2 requires 64 bit Windows 7 or newer. Enter your desired Installation Folder (short ASCII-only path on a NTFS volume, no accents, no spaces, no symlinks, no subst or network drives, no FAT). When done, tick Run MSYS2 now . Update the package database and base packages. Unless your setup file is very recent, it will take two steps. First run pacman -Syu : $ pacman -Syu :: Synchronizing package databases... mingw32 805.0 KiB mingw32.sig 438.0 B mingw64 807.9 KiB mingw64.sig 438.0 B msys 289.3 KiB msys.sig 438.0 B :: Starting core system upgrade... warning: terminate other MSYS2 programs before proceeding resolving dependencies... looking for conflicting packages... Packages (6) bash-5.1.004-1 filesystem-2021.01-1 mintty-1~3.4.4-1 msys2-runtime-3.1.7-4 pacman-5.2.2-9 pacman-mirrors-20201208-1 Total Download Size: 11.05 MiB Total Installed Size: 53.92 MiB Net Upgrade Size: -1.24 MiB :: Proceed with installation? [Y/n] :: Retrieving packages... bash-5.1.004-1-x86_64 2.3 MiB filesystem-2021.01-1-any 33.2 KiB mintty-1~3.4.4-1-x86_64 767.2 KiB msys2-runtime-3.1.7-4-x86_64 2.6 MiB pacman-mirrors-20201208-1-any 3.8 KiB pacman-5.2.2-9-x86_64 5.4 MiB (6/6) checking keys in keyring 100% (6/6) checking package integrity 100% (6/6) loading package files 100% (6/6) checking for file conflicts 100% (6/6) checking available disk space 100% :: Processing package changes... (1/6) upgrading bash 100% (2/6) upgrading filesystem 100% (3/6) upgrading mintty 100% (4/6) upgrading msys2-runtime 100% (5/6) upgrading pacman-mirrors 100% (6/6) upgrading pacman 100% :: To complete this update all MSYS2 processes including this terminal will be closed. Confirm to proceed [Y/n] Run \"MSYS2 MSYS\" from Start menu. Update the rest of the base packages with pacman -Su : $ pacman -Su :: Starting core system upgrade... there is nothing to do :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... Packages (20) base-2020.12-1 bsdtar-3.5.0-1 [... more packages listed ...] Total Download Size: 12.82 MiB Total Installed Size: 44.25 MiB Net Upgrade Size: 3.01 MiB :: Proceed with installation? [Y/n] [... downloading and installation continues ...] Now MSYS2 is ready for you. You will probably want to install some tools and the mingw-w64 GCC to start compiling: $ pacman -S --needed base-devel mingw-w64-x86_64-toolchain warning: file-5.39-2 is up to date -- skipping [... more warnings ...] :: There are 48 members in group base-devel: :: Repository msys 1) asciidoc 2) autoconf 3) autoconf2.13 4) autogen [... more packages listed ...] Enter a selection (default=all): :: There are 19 members in group mingw-w64-x86_64-toolchain: :: Repository mingw64 1) mingw-w64-x86_64-binutils 2) mingw-w64-x86_64-crt-git [... more packages listed ...] Enter a selection (default=all): resolving dependencies... looking for conflicting packages... Packages (123) docbook-xml-4.5-2 docbook-xsl-1.79.2-1 [... more packages listed ...] m4-1.4.18-2 make-4.3-1 man-db-2.9.3-1 mingw-w64-x86_64-binutils-2.35.1-3 mingw-w64-x86_64-crt-git-9.0.0.6090.ad98746a-1 mingw-w64-x86_64-gcc-10.2.0-6 mingw-w64-x86_64-gcc-ada-10.2.0-6 mingw-w64-x86_64-gcc-fortran-10.2.0-6 mingw-w64-x86_64-gcc-libgfortran-10.2.0-6 mingw-w64-x86_64-gcc-libs-10.2.0-6 mingw-w64-x86_64-gcc-objc-10.2.0-6 mingw-w64-x86_64-gdb-10.1-2 mingw-w64-x86_64-gdb-multiarch-10.1-2 [... more packages listed ...] Total Download Size: 196.15 MiB Total Installed Size: 1254.96 MiB :: Proceed with installation? [Y/n] [... downloading and installation continues ...] To start building using the mingw-w64 GCC, close this window and run \"MSYS MinGW 64-bit\" from Start menu. Now you can call make or gcc to build software for Windows. Check out the introduction page to learn which Start menu item to use when and which packages to install. Take look at Detailed MSYS2 install guide for troubleshooting and additional details on how to keep your MSYS2 up-to-date.","title":"Installation"},{"location":"#sponsors","text":"Our main server is sponsored by jsdelivr.com","title":"Sponsors"},{"location":"#authors-and-contributors","text":"Alexpux (Alexey Pavlov) martell (Martell Malone) mingwandroid (Ray Donnelly) Elieux (David Macek) lazka (Christoph Reiter) Renato Silva niXman naveen521kk (Naveen M K) Biswa96 (Biswapriyo Nath) jeremyd2019 (Jeremy Drake) mati865 (Mateusz Miku\u0142a)","title":"Authors and Contributors"},{"location":"#donations","text":"","title":"Donations"},{"location":"#alexey-pavlov-alexpux","text":"WebMoney transfer to the following WebMoney wallets: E271473533800 R691797957081 Z110171850957 PayPal: alexpux@gmail.com Yandex.Money: 41001429355429","title":"Alexey Pavlov (@alexpux)"},{"location":"#ray-donnelly-mingwandroid","text":"See https://www.msys2.org/news/#2021-04-21-rip-mingwandroid","title":"Ray Donnelly (@mingwandroid)"},{"location":"#christoph-reiter-lazka","text":"GitHub Sponsors: https://github.com/sponsors/lazka PayPal: reiter.christoph@gmail.com","title":"Christoph Reiter (@lazka)"},{"location":"codeofconduct/","text":"Code of Conduct Contact for CoC related Issues Christoph Reiter reiter.christoph@gmail.com If for some reason you want to contact someone else or if there is no timely response: David Macek david.macek.0@gmail.com Our Pledge We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. Our Standards Examples of behavior that contributes to a positive environment for our community include: Demonstrating empathy and kindness toward other people Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Enforcement Responsibilities Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. Scope This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at -> please see \"Contact for CoC related Issues\" above. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. Enforcement Guidelines Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: 1. Correction Community Impact : Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. Consequence : A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. 2. Warning Community Impact : A violation through a single incident or series of actions. Consequence : A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. 3. Temporary Ban Community Impact : A serious violation of community standards, including sustained inappropriate behavior. Consequence : A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. 4. Permanent Ban Community Impact : Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. Consequence : A permanent ban from any sort of public interaction within the community. Attribution This Code of Conduct is adapted from the Contributor Covenant , version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html . Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder . For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq . Translations are available at https://www.contributor-covenant.org/translations .","title":"Code of Conduct"},{"location":"codeofconduct/#code-of-conduct","text":"","title":"Code of Conduct"},{"location":"codeofconduct/#contact-for-coc-related-issues","text":"Christoph Reiter reiter.christoph@gmail.com If for some reason you want to contact someone else or if there is no timely response: David Macek david.macek.0@gmail.com","title":"Contact for CoC related Issues"},{"location":"codeofconduct/#our-pledge","text":"We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.","title":"Our Pledge"},{"location":"codeofconduct/#our-standards","text":"Examples of behavior that contributes to a positive environment for our community include: Demonstrating empathy and kindness toward other people Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting","title":"Our Standards"},{"location":"codeofconduct/#enforcement-responsibilities","text":"Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.","title":"Enforcement Responsibilities"},{"location":"codeofconduct/#scope","text":"This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.","title":"Scope"},{"location":"codeofconduct/#enforcement","text":"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at -> please see \"Contact for CoC related Issues\" above. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident.","title":"Enforcement"},{"location":"codeofconduct/#enforcement-guidelines","text":"Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:","title":"Enforcement Guidelines"},{"location":"codeofconduct/#1-correction","text":"Community Impact : Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. Consequence : A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.","title":"1. Correction"},{"location":"codeofconduct/#2-warning","text":"Community Impact : A violation through a single incident or series of actions. Consequence : A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.","title":"2. Warning"},{"location":"codeofconduct/#3-temporary-ban","text":"Community Impact : A serious violation of community standards, including sustained inappropriate behavior. Consequence : A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.","title":"3. Temporary Ban"},{"location":"codeofconduct/#4-permanent-ban","text":"Community Impact : Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. Consequence : A permanent ban from any sort of public interaction within the community.","title":"4. Permanent Ban"},{"location":"codeofconduct/#attribution","text":"This Code of Conduct is adapted from the Contributor Covenant , version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html . Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder . For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq . Translations are available at https://www.contributor-covenant.org/translations .","title":"Attribution"},{"location":"contact/","text":"Support & Contact read our wiki browse our package lists search for and file issues for msys2 packages on GitHub search for and file issues for mingw-w64 packages on GitHub search for very old tickets on SourceForge read and post to our mailing list talk in our Gitter room talk in our Discord server talk in our IRC channel follow our Twitter account read older discussion on SourceForge more links on our homepage on GitHub Security Contact For reporting vulnerabilities, managing coordinated security updates, or anything which shouldn't be posted to the public GitHub issue tracker: Contact: reiter.christoph@gmail.com PGP key for encryption, if needed: https://keyserver.ubuntu.com/pks/lookup?op=vindex&search=0x46BD761F7A49B0EC&fingerprint=on If there is no timely response please ping us on the other support channels.","title":"Support & Contact"},{"location":"contact/#support-contact","text":"read our wiki browse our package lists search for and file issues for msys2 packages on GitHub search for and file issues for mingw-w64 packages on GitHub search for very old tickets on SourceForge read and post to our mailing list talk in our Gitter room talk in our Discord server talk in our IRC channel follow our Twitter account read older discussion on SourceForge more links on our homepage on GitHub","title":"Support &amp; Contact"},{"location":"contact/#security-contact","text":"For reporting vulnerabilities, managing coordinated security updates, or anything which shouldn't be posted to the public GitHub issue tracker: Contact: reiter.christoph@gmail.com PGP key for encryption, if needed: https://keyserver.ubuntu.com/pks/lookup?op=vindex&search=0x46BD761F7A49B0EC&fingerprint=on If there is no timely response please ping us on the other support channels.","title":"Security Contact"},{"location":"news/","text":"News 2021-10-14 - OpenSSH 8.8 dropped support for old ssh-rsa keys using SHA-1 The recent OpenSSH update disabled support for old ssh-rsa keys using SHA-1 by default. See https://www.openssh.com/txt/release-8.8 \"Potentially-incompatible changes\" for details and possible workarounds. 2021-07-04 - Some Mirror/Server/Repository Changes Primary Pacman Server : We've switched the main server in the pacman config to https://mirror.msys2.org . This server will redirect pacman to an up-to-date mirror near you for each file. We hope this will improve the download speed for users further away from Europe. We also have a new overview of all mirrors here . Repo Path Renaming: We've renamed mingw/i686/ to mingw/mingw32/ and mingw/x86_86/ to mingw/mingw64/ and added symlinks for the old paths. This means 100GB of resyncing for mirrors using rsync (sorry :/). Having the repo name in the directory path allows us to have one mirrorlist configuration for all repos in the future. Sourceforge : Due to space constraints we no longer host the source packages on Sourceforge. They are still available on our main server and on all mirrors. 2021-04-21 - R.I.P. mingwandroid Ray Donnelly is a co-founder and developer of MSYS2 and after a multi year fight with cancer passed away on 2021-04-20. If you want to know more about his life and work see his fundraiser descriptions: https://uk.gofundme.com/f/help-Ray-fund-a-hospice-bedroom https://uk.gofundme.com/f/arku72-help-ray-fight-cancer He was always helpful, knowledgeable, and friendly, and he will be greatly missed. 2021-03-25 - Temporarily broken msys2-launcher package The repo contained a broken msys2-launcher package for a few hours today causing things like \"msys2.exe\" to just show an error dialog. You can get back to a working setup this way: Start C:/msys64/msys2_shell.cmd to get a shell Run pacman -Suy to get all the fixed packages 2021-02-27 - New server for repo.msys2.org and packages.msys2.org We have moved repo.msys2.org (and package.msys2.org) to a new server. There was a short downtime, but everything should be running great now. Big thanks to appfleet.com jsdelivr.com for sponsoring the new server. New mirrorlists for Pacman will be published soon. After you get them, your package installs and updates should be faster than before and without the 404s and glitches. With the migration, Christoph (@lazka) will now be updating and signing the Pacman databases more often. This should go smoothly as the GPG keys are already in place and the process has been tested on the new server before it went live. By the way, the redirect domain msys2.org (no www.) should work more reliably now and HTTPS is now available for it. 2021-01-31 - ASLR enabled by default About 5 months ago we started backporting patches to our binutils 2.35 to allow enabling ASLR support via various flags. We also enabled these flags in our build system, so any package in our repo that was updated in the last 5 months has ASLR support enabled. We've now updated to 2.36 which has ASLR enabled by default. Ideally you shouldn't notice any changes, but in case this leads to problems all of it can be disabled/reverted via linker flags: mingw64: -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low mingw32: -Wl,--disable-dynamicbase Note that this is only a temporary workaround and some of these flags will not be available forever, so you should either fix your code or file a bug in case you suspect a toolchain issue. Thanks to the binutils developers for improving/fixing ASLR support and to everyone helping on the MSYS2 side of things, especially Jeremy Drake for backporting, upstreaming and fixing bugs exposed by these changes. Known issues: (Fixed now) In case you are seeing errors such as relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol try building with -Wl,--default-image-base-low . Here is the upstream bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=26659 2020-12-26 - Zstd exemption for core packages removed Given it's been months since we began the switch to Zstd for compressing packages, we've now started using it for core packages as well. This means older installations without Zstd support won't be able to cleanly upgrade anymore. @dmn-star compiled these commands that should update an older installation to support Zstd and unblock futher upgrades: pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/libzstd-1.4.4-2-x86_64.pkg.tar.xz\" pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/zstd-1.4.4-2-x86_64.pkg.tar.xz\" pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/pacman-5.2.1-6-x86_64.pkg.tar.xz\" 2020-10-08 - main repo pruned Due to limited space on the new server and SourceForge file hosting, we are starting to remove older unused packages from the archives. There should still be a 1 year's worth of packages available for downgrades. Mirrors are free to choose whether they want to keep everything or follow the lead. 2020-10-07 - server downtime From Friday 2 nd to Wednesday 10 th , the main hosting at repo.msys2.org was down. The server unfortunately completely died and the hosting had to be moved elsewhere. We thank Diablo-D3 for having provided the hardware and hosting. If you notice anything wrong with repo.msys2.org since the move, please tell us. 2020-06-29 - new packagers Alexey is stepping down from his role as the main packager and two new packagers have been appointed in his place: David Macek with signing key 0x9078f532 Christoph Reiter with signing key 0xa0aa7f57 You can see the keys in full without relying on keyservers in the msys2-keyring GitHub repository . We have released a new msys2-keyring package from that source (and a new installer that includes them) and we are waiting for a bit before uploading new databases and packages to give people time to update. If you don't update the keyring in time, you'll see something like this: :: Synchronizing package databases... downloading mingw32.db... downloading mingw32.db.sig... error: mingw32: key \"4A6129F4E4B84AE46ED7F635628F528CF3053E04\" is unknown :: Import PGP key 4096R/87771331B3F1FF5263856A6D974C8BE49078F532, \"David Macek <david.macek.0@gmail.com>\", created: 2018-01-14? [Y/n] error: mingw32: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update mingw32 (invalid or corrupted database (PGP signature)) downloading mingw64.db... downloading mingw64.db.sig... error: mingw64: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update mingw64 (invalid or corrupted database (PGP signature)) downloading msys.db... downloading msys.db.sig... error: msys: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update msys (invalid or corrupted database (PGP signature)) error: failed to synchronize all databases error: mingw32: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: mingw64: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: msys: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust We have prepared the following steps to verify and install the new keyring manually after which you should be able to use pacman -Syu again: $ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz $ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig $ pacman-key --verify msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig ==> Checking msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig... (detached) gpg: Signature made Mon Jun 29 07:36:14 2020 CEST gpg: using DSA key AD351C50AE085775EB59333B5F92EFC1A47D45A1 gpg: Good signature from \"Alexey Pavlov (Alexpux) <alexpux@gmail.com>\" [full] # pacman -U msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz If you can't even import the key and the above command fails like this: error: msys: key \"4A6129F4E4B84AE46ED7F635628F528CF3053E04\" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] [...] error: database 'msys' is not valid (invalid or corrupted database (PGP signature)) loading packages... error: failed to prepare transaction (invalid or corrupted database) ... you have to convince pacman to not care about those databases for a while, for example like this: # pacman -U --config <(echo) msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz If you still see signature errors, resetting your pacman key store might help: # rm -r /etc/pacman.d/gnupg/ # pacman-key --init # pacman-key --populate msys2 2020-06-15 - New base metapackage; pacman-contrib is now separate Following a similar change in Arch Linux, the base group was replaced with a base metapackage. If you installed your MSYS2 using an installer older than 2020-06-02, please run pacman -S base to get up to date. This also installs the pacman-contrib package where updpkgsums , pactree etc. now live (previously included in the pacman package). Details at #1979 , #1976 and #1988 . 2020-05-31 - Update may fail with \"could not open file\" In case your update process errors out with something similar to error: could not open file /var/cache/pacman/pkg/zstd-1.4.5-1-x86_64.pkg.tar.zst: Child process exited with status 127 update pacman separately first: pacman -Sydd pacman This issue is caused by a pacman version that is too old and can't handle newer packages compressed with zstd. In case you are seeing this problem in CI consider using a newer base which contains a newer pacman which supports zstd: https://github.com/msys2/msys2-installer/releases 2020-05-22 - MSYS2 may fail to start after a msys2-runtime upgrade MSYS2 programs will fail to start if programs started before the update are still running in the background (especially sshd, dirmngr, gpg-agent, bash, pacman and mintty). You can stop them by running the following in a Windows terminal: taskkill /f /fi \"MODULES eq msys-2.0.dll\" If that fails, try a reboot. We've improved our update process so this shouldn't happen again with future updates. 2020-05-22 - Pacman may fail to install packages with Unrecognized archive format For a while, the core packages were prematurely packaged using zstd without giving users time to update to zstd-enabled pacman first. This should be resolved now. 2020-05-17 - 32-bit MSYS2 no longer actively supported 32-bit mingw-w64 packages are still supported, this is about the POSIX emulation layer, i.e. the runtime, Bash, MinTTY... After this date, we don't plan on building updated msys-i686 packages nor releasing i686 installers anymore. This is due to increasingly frustrating difficulties with limited 32-bit address space, high penetration of 64-bit systems and Cygwin (our upstream) starting their way to drop 32-bit support as well. 2019-06-03 - mingw-w64 Ada and ObjC unsupported until further notice Pacman may say this when updating: looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-objc :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-objc Ada and ObjC are currently unsupported in MSYS2 builds due to long-standing issues with the i686 variant. Run pacman -R mingw-w64-x86_64-gcc-ada mingw-w64-x86_64-gcc-objc and/or pacman -R mingw-w64-i686-gcc-ada mingw-w64-i686-gcc-objc , then update. 2016 - Core update integrated into Pacman; update-core removed The function of update-core is transferred to pacman -Syuu . 2016 - Command window may linger after startup Change the argument /K to /C in all three Start menu shortcuts.","title":"News"},{"location":"news/#news","text":"","title":"News"},{"location":"news/#2021-10-14-openssh-88-dropped-support-for-old-ssh-rsa-keys-using-sha-1","text":"The recent OpenSSH update disabled support for old ssh-rsa keys using SHA-1 by default. See https://www.openssh.com/txt/release-8.8 \"Potentially-incompatible changes\" for details and possible workarounds.","title":"2021-10-14 - OpenSSH 8.8 dropped support for old ssh-rsa keys using SHA-1"},{"location":"news/#2021-07-04-some-mirrorserverrepository-changes","text":"Primary Pacman Server : We've switched the main server in the pacman config to https://mirror.msys2.org . This server will redirect pacman to an up-to-date mirror near you for each file. We hope this will improve the download speed for users further away from Europe. We also have a new overview of all mirrors here . Repo Path Renaming: We've renamed mingw/i686/ to mingw/mingw32/ and mingw/x86_86/ to mingw/mingw64/ and added symlinks for the old paths. This means 100GB of resyncing for mirrors using rsync (sorry :/). Having the repo name in the directory path allows us to have one mirrorlist configuration for all repos in the future. Sourceforge : Due to space constraints we no longer host the source packages on Sourceforge. They are still available on our main server and on all mirrors.","title":"2021-07-04 - Some Mirror/Server/Repository Changes"},{"location":"news/#2021-04-21-rip-mingwandroid","text":"Ray Donnelly is a co-founder and developer of MSYS2 and after a multi year fight with cancer passed away on 2021-04-20. If you want to know more about his life and work see his fundraiser descriptions: https://uk.gofundme.com/f/help-Ray-fund-a-hospice-bedroom https://uk.gofundme.com/f/arku72-help-ray-fight-cancer He was always helpful, knowledgeable, and friendly, and he will be greatly missed.","title":"2021-04-21 - R.I.P. mingwandroid"},{"location":"news/#2021-03-25-temporarily-broken-msys2-launcher-package","text":"The repo contained a broken msys2-launcher package for a few hours today causing things like \"msys2.exe\" to just show an error dialog. You can get back to a working setup this way: Start C:/msys64/msys2_shell.cmd to get a shell Run pacman -Suy to get all the fixed packages","title":"2021-03-25 - Temporarily broken msys2-launcher package"},{"location":"news/#2021-02-27-new-server-for-repomsys2org-and-packagesmsys2org","text":"We have moved repo.msys2.org (and package.msys2.org) to a new server. There was a short downtime, but everything should be running great now. Big thanks to appfleet.com jsdelivr.com for sponsoring the new server. New mirrorlists for Pacman will be published soon. After you get them, your package installs and updates should be faster than before and without the 404s and glitches. With the migration, Christoph (@lazka) will now be updating and signing the Pacman databases more often. This should go smoothly as the GPG keys are already in place and the process has been tested on the new server before it went live. By the way, the redirect domain msys2.org (no www.) should work more reliably now and HTTPS is now available for it.","title":"2021-02-27 - New server for repo.msys2.org and packages.msys2.org"},{"location":"news/#2021-01-31-aslr-enabled-by-default","text":"About 5 months ago we started backporting patches to our binutils 2.35 to allow enabling ASLR support via various flags. We also enabled these flags in our build system, so any package in our repo that was updated in the last 5 months has ASLR support enabled. We've now updated to 2.36 which has ASLR enabled by default. Ideally you shouldn't notice any changes, but in case this leads to problems all of it can be disabled/reverted via linker flags: mingw64: -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low mingw32: -Wl,--disable-dynamicbase Note that this is only a temporary workaround and some of these flags will not be available forever, so you should either fix your code or file a bug in case you suspect a toolchain issue. Thanks to the binutils developers for improving/fixing ASLR support and to everyone helping on the MSYS2 side of things, especially Jeremy Drake for backporting, upstreaming and fixing bugs exposed by these changes. Known issues: (Fixed now) In case you are seeing errors such as relocation truncated to fit: IMAGE_REL_AMD64_REL32 against undefined symbol try building with -Wl,--default-image-base-low . Here is the upstream bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=26659","title":"2021-01-31 - ASLR enabled by default"},{"location":"news/#2020-12-26-zstd-exemption-for-core-packages-removed","text":"Given it's been months since we began the switch to Zstd for compressing packages, we've now started using it for core packages as well. This means older installations without Zstd support won't be able to cleanly upgrade anymore. @dmn-star compiled these commands that should update an older installation to support Zstd and unblock futher upgrades: pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/libzstd-1.4.4-2-x86_64.pkg.tar.xz\" pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/zstd-1.4.4-2-x86_64.pkg.tar.xz\" pacman --noconfirm -U \"https://repo.msys2.org/msys/x86_64/pacman-5.2.1-6-x86_64.pkg.tar.xz\"","title":"2020-12-26 - Zstd exemption for core packages removed"},{"location":"news/#2020-10-08-main-repo-pruned","text":"Due to limited space on the new server and SourceForge file hosting, we are starting to remove older unused packages from the archives. There should still be a 1 year's worth of packages available for downgrades. Mirrors are free to choose whether they want to keep everything or follow the lead.","title":"2020-10-08 - main repo pruned"},{"location":"news/#2020-10-07-server-downtime","text":"From Friday 2 nd to Wednesday 10 th , the main hosting at repo.msys2.org was down. The server unfortunately completely died and the hosting had to be moved elsewhere. We thank Diablo-D3 for having provided the hardware and hosting. If you notice anything wrong with repo.msys2.org since the move, please tell us.","title":"2020-10-07 - server downtime"},{"location":"news/#2020-06-29-new-packagers","text":"Alexey is stepping down from his role as the main packager and two new packagers have been appointed in his place: David Macek with signing key 0x9078f532 Christoph Reiter with signing key 0xa0aa7f57 You can see the keys in full without relying on keyservers in the msys2-keyring GitHub repository . We have released a new msys2-keyring package from that source (and a new installer that includes them) and we are waiting for a bit before uploading new databases and packages to give people time to update. If you don't update the keyring in time, you'll see something like this: :: Synchronizing package databases... downloading mingw32.db... downloading mingw32.db.sig... error: mingw32: key \"4A6129F4E4B84AE46ED7F635628F528CF3053E04\" is unknown :: Import PGP key 4096R/87771331B3F1FF5263856A6D974C8BE49078F532, \"David Macek <david.macek.0@gmail.com>\", created: 2018-01-14? [Y/n] error: mingw32: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update mingw32 (invalid or corrupted database (PGP signature)) downloading mingw64.db... downloading mingw64.db.sig... error: mingw64: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update mingw64 (invalid or corrupted database (PGP signature)) downloading msys.db... downloading msys.db.sig... error: msys: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: failed to update msys (invalid or corrupted database (PGP signature)) error: failed to synchronize all databases error: mingw32: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: mingw64: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust error: msys: signature from \"David Macek <david.macek.0@gmail.com>\" is marginal trust We have prepared the following steps to verify and install the new keyring manually after which you should be able to use pacman -Syu again: $ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz $ curl -O https://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig $ pacman-key --verify msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig ==> Checking msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz.sig... (detached) gpg: Signature made Mon Jun 29 07:36:14 2020 CEST gpg: using DSA key AD351C50AE085775EB59333B5F92EFC1A47D45A1 gpg: Good signature from \"Alexey Pavlov (Alexpux) <alexpux@gmail.com>\" [full] # pacman -U msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz If you can't even import the key and the above command fails like this: error: msys: key \"4A6129F4E4B84AE46ED7F635628F528CF3053E04\" is unknown :: Import PGP key 4A6129F4E4B84AE46ED7F635628F528CF3053E04? [Y/n] [...] error: database 'msys' is not valid (invalid or corrupted database (PGP signature)) loading packages... error: failed to prepare transaction (invalid or corrupted database) ... you have to convince pacman to not care about those databases for a while, for example like this: # pacman -U --config <(echo) msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz If you still see signature errors, resetting your pacman key store might help: # rm -r /etc/pacman.d/gnupg/ # pacman-key --init # pacman-key --populate msys2","title":"2020-06-29 - new packagers"},{"location":"news/#2020-06-15-new-base-metapackage-pacman-contrib-is-now-separate","text":"Following a similar change in Arch Linux, the base group was replaced with a base metapackage. If you installed your MSYS2 using an installer older than 2020-06-02, please run pacman -S base to get up to date. This also installs the pacman-contrib package where updpkgsums , pactree etc. now live (previously included in the pacman package). Details at #1979 , #1976 and #1988 .","title":"2020-06-15 - New base metapackage; pacman-contrib is now separate"},{"location":"news/#2020-05-31-update-may-fail-with-could-not-open-file","text":"In case your update process errors out with something similar to error: could not open file /var/cache/pacman/pkg/zstd-1.4.5-1-x86_64.pkg.tar.zst: Child process exited with status 127 update pacman separately first: pacman -Sydd pacman This issue is caused by a pacman version that is too old and can't handle newer packages compressed with zstd. In case you are seeing this problem in CI consider using a newer base which contains a newer pacman which supports zstd: https://github.com/msys2/msys2-installer/releases","title":"2020-05-31 - Update may fail with \"could not open file\""},{"location":"news/#2020-05-22-msys2-may-fail-to-start-after-a-msys2-runtime-upgrade","text":"MSYS2 programs will fail to start if programs started before the update are still running in the background (especially sshd, dirmngr, gpg-agent, bash, pacman and mintty). You can stop them by running the following in a Windows terminal: taskkill /f /fi \"MODULES eq msys-2.0.dll\" If that fails, try a reboot. We've improved our update process so this shouldn't happen again with future updates.","title":"2020-05-22 - MSYS2 may fail to start after a msys2-runtime upgrade"},{"location":"news/#2020-05-22-pacman-may-fail-to-install-packages-with-unrecognized-archive-format","text":"For a while, the core packages were prematurely packaged using zstd without giving users time to update to zstd-enabled pacman first. This should be resolved now.","title":"2020-05-22 - Pacman may fail to install packages with Unrecognized archive format"},{"location":"news/#2020-05-17-32-bit-msys2-no-longer-actively-supported","text":"32-bit mingw-w64 packages are still supported, this is about the POSIX emulation layer, i.e. the runtime, Bash, MinTTY... After this date, we don't plan on building updated msys-i686 packages nor releasing i686 installers anymore. This is due to increasingly frustrating difficulties with limited 32-bit address space, high penetration of 64-bit systems and Cygwin (our upstream) starting their way to drop 32-bit support as well.","title":"2020-05-17 - 32-bit MSYS2 no longer actively supported"},{"location":"news/#2019-06-03-mingw-w64-ada-and-objc-unsupported-until-further-notice","text":"Pacman may say this when updating: looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-x86_64-gcc=8.3.0-2' required by mingw-w64-x86_64-gcc-objc :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-ada :: installing mingw-w64-x86_64-gcc (9.1.0-1) breaks dependency 'mingw-w64-i686-gcc=8.3.0-2' required by mingw-w64-i686-gcc-objc Ada and ObjC are currently unsupported in MSYS2 builds due to long-standing issues with the i686 variant. Run pacman -R mingw-w64-x86_64-gcc-ada mingw-w64-x86_64-gcc-objc and/or pacman -R mingw-w64-i686-gcc-ada mingw-w64-i686-gcc-objc , then update.","title":"2019-06-03 - mingw-w64 Ada and ObjC unsupported until further notice"},{"location":"news/#2016-core-update-integrated-into-pacman-update-core-removed","text":"The function of update-core is transferred to pacman -Syuu .","title":"2016 - Core update integrated into Pacman; update-core removed"},{"location":"news/#2016-command-window-may-linger-after-startup","text":"Change the argument /K to /C in all three Start menu shortcuts.","title":"2016 - Command window may linger after startup"},{"location":"dev/keyring/","text":"MSYS2 Keyring Repository: https://github.com/msys2/MSYS2-keyring Also see https://wiki.archlinux.org/index.php/Pacman/Package_signing Master Keys Master Key Full Fingerprint Owner 0xF40D263ECA25678A D55E 7A6D 7CE9 BA15 87C0 ACAC F40D 263E CA25 678A alexpux 0xBBE514E53E0D0813 123D 4D51 A179 3859 C2BE 916B BBE5 14E5 3E0D 0813 mingwandroid 0x9F418C233E652008 B91B CF33 0328 4BF9 0CC0 43CA 9F41 8C23 3E65 2008 nacho 0xDA7EF2ABAEEA755C 9DD0 D421 7D75 A33B 8961 59E6 DA7E F2AB AEEA 755C martell 0x790AE56A1D3CFDDC 6E8F EAFF 9644 F54E ED90 EEA0 790A E56A 1D3C FDDC elieux 0x755B8182ACD22879 6998 5C5E B351 011C 78DF 7F6D 755B 8182 ACD2 2879 lazka Developer Keys Each of these keys is signed by at least three master keys. Developer Key Full Fingerprint Owner 0x5F92EFC1A47D45A1 AD35 1C50 AE08 5775 EB59 333B 5F92 EFC1 A47D 45A1 alexpux 0x4DF3B7664CA56930 909F 9599 D1A2 046B 21FA EB3C 4DF3 B766 4CA5 6930 mingwandroid 0xD595C9AB2C51581E C65E C896 6983 541D 52B9 7A16 D595 C9AB 2C51 581E martell 0x974C8BE49078F532 8777 1331 B3F1 FF52 6385 6A6D 974C 8BE4 9078 F532 elieux 0xFA11531AA0AA7F57 5F94 4B02 7F7F E209 1985 AA2E FA11 531A A0AA 7F57 lazka","title":"MSYS2 Keyring"},{"location":"dev/keyring/#msys2-keyring","text":"Repository: https://github.com/msys2/MSYS2-keyring Also see https://wiki.archlinux.org/index.php/Pacman/Package_signing","title":"MSYS2 Keyring"},{"location":"dev/keyring/#master-keys","text":"Master Key Full Fingerprint Owner 0xF40D263ECA25678A D55E 7A6D 7CE9 BA15 87C0 ACAC F40D 263E CA25 678A alexpux 0xBBE514E53E0D0813 123D 4D51 A179 3859 C2BE 916B BBE5 14E5 3E0D 0813 mingwandroid 0x9F418C233E652008 B91B CF33 0328 4BF9 0CC0 43CA 9F41 8C23 3E65 2008 nacho 0xDA7EF2ABAEEA755C 9DD0 D421 7D75 A33B 8961 59E6 DA7E F2AB AEEA 755C martell 0x790AE56A1D3CFDDC 6E8F EAFF 9644 F54E ED90 EEA0 790A E56A 1D3C FDDC elieux 0x755B8182ACD22879 6998 5C5E B351 011C 78DF 7F6D 755B 8182 ACD2 2879 lazka","title":"Master Keys"},{"location":"dev/keyring/#developer-keys","text":"Each of these keys is signed by at least three master keys. Developer Key Full Fingerprint Owner 0x5F92EFC1A47D45A1 AD35 1C50 AE08 5775 EB59 333B 5F92 EFC1 A47D 45A1 alexpux 0x4DF3B7664CA56930 909F 9599 D1A2 046B 21FA EB3C 4DF3 B766 4CA5 6930 mingwandroid 0xD595C9AB2C51581E C65E C896 6983 541D 52B9 7A16 D595 C9AB 2C51 581E martell 0x974C8BE49078F532 8777 1331 B3F1 FF52 6385 6A6D 974C 8BE4 9078 F532 elieux 0xFA11531AA0AA7F57 5F94 4B02 7F7F E209 1985 AA2E FA11 531A A0AA 7F57 lazka","title":"Developer Keys"},{"location":"dev/mirrors/","text":"Mirrors Our main repo server is located in Germany and contains the pacman databases and packages, matching source packages and installers. The whole content of the mirror is regularly synced to multiple mirrors across the world. All these servers are registered with pacman under /etc/pacman.d/mirrorlist.* . The first URL in those lists is the primary mirror, all others will be used as a fallback. You can make another mirror the primary one by moving it to the top. In case you have problems with a particular mirror please let us know by filing an issue: https://github.com/msys2/msys2.github.io/issues Primary Server Name URL Contact Note repo.msys2.org HTTPS | RSYNC contact primary mirror.msys2.org HTTPS contact geo redirection service for Tier 1 mirrors Tier 1 Mirrors Requirements: Reliable, 1GBit/s+ with enough free bandwidth, rsync server support, HTTPS support, synced at least once per day from the primary server. Map : https://mirror.msys2.org/?mirrorstats Name URLs Contact Note download.nus.edu.sg HTTPS | RSYNC download@nus.edu.sg ftp.acc.umu.se HTTPS | RSYNC ftp-adm@acc.umu.se ftp.nluug.nl HTTPS | RSYNC ftp-admin@nluug.nl ftp.osuosl.org HTTPS | RSYNC hosting-request@osuosl.org mirror.clarkson.edu HTTPS | RSYNC Cameron Weinfurt mirror.internet.asn.au HTTPS | RSYNC peering@ix.asn.au mirror.selfnet.de HTTPS | RSYNC mirror.ufro.cl HTTPS | RSYNC Jonathan Guti\u00e9rrez mirror.yandex.ru HTTPS | RSYNC - mirrors.dotsrc.org HTTPS | RSYNC staff@dotsrc.org mirrors.tuna.tsinghua.edu.cn HTTPS | RSYNC - mirrors.ustc.edu.cn HTTPS | RSYNC lug@ustc.edu.cn mirror.nju.edu.cn HTTPS | RSYNC my@yaoge123.com Tier 2 Mirrors Requirements: Synced regularly. Name URLs Contact Note downloads.sourceforge.net HTTPS contact fastmirror.pp.ua HTTPS | RSYNC smlr@ukr.net (too slow for T1) ftp.cc.uoc.gr HTTPS mirrors@cc.uoc.gr mirrors.bit.edu.cn HTTPS webmaster@bitnp.net mirror.jmu.edu HTTPS mirrormaster@jmu.edu mirrors.piconets.webwerks.in HTTPS mirrors@piconets.com mirrors.sjtug.sjtu.edu.cn HTTPS quantum-mirror.hu HTTPS | RSYNC root@quantum-mirror.hu (too slow for T1) www2.futureware.at HTTPS Nick \u00d8stergaard repo.casualgamer.ca HTTPS Adding a New Mirror The repository size is ~240 GiB (see https://mirror.jmu.edu/ for current stats) with the distribution of sizes like this: -1K: ~14000 files -100K: ~3200 files -1M: ~5000 files -10M: ~4000 files -100M: ~1000 files -1G: ~200 files -10G: ~20 files You can use rsync to update your mirror using rsync -rtlvH --delete-after --delay-updates --safe-links \\ rsync://repo.msys2.org/builds/ ./msys2 Our repository layout is compatible with Arch Linux, which means you can use the following script to sync everything more frequently and efficiently: https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/syncrepo/files/syncrepo-template.sh source_url = 'rsync://repo.msys2.org/builds/' lastupdate_url = 'https://repo.msys2.org/lastupdate' To register your mirror please open an issue here: https://github.com/msys2/msys2.github.io/issues","title":"Mirrors"},{"location":"dev/mirrors/#mirrors","text":"Our main repo server is located in Germany and contains the pacman databases and packages, matching source packages and installers. The whole content of the mirror is regularly synced to multiple mirrors across the world. All these servers are registered with pacman under /etc/pacman.d/mirrorlist.* . The first URL in those lists is the primary mirror, all others will be used as a fallback. You can make another mirror the primary one by moving it to the top. In case you have problems with a particular mirror please let us know by filing an issue: https://github.com/msys2/msys2.github.io/issues","title":"Mirrors"},{"location":"dev/mirrors/#primary-server","text":"Name URL Contact Note repo.msys2.org HTTPS | RSYNC contact primary mirror.msys2.org HTTPS contact geo redirection service for Tier 1 mirrors","title":"Primary Server"},{"location":"dev/mirrors/#tier-1-mirrors","text":"Requirements: Reliable, 1GBit/s+ with enough free bandwidth, rsync server support, HTTPS support, synced at least once per day from the primary server. Map : https://mirror.msys2.org/?mirrorstats Name URLs Contact Note download.nus.edu.sg HTTPS | RSYNC download@nus.edu.sg ftp.acc.umu.se HTTPS | RSYNC ftp-adm@acc.umu.se ftp.nluug.nl HTTPS | RSYNC ftp-admin@nluug.nl ftp.osuosl.org HTTPS | RSYNC hosting-request@osuosl.org mirror.clarkson.edu HTTPS | RSYNC Cameron Weinfurt mirror.internet.asn.au HTTPS | RSYNC peering@ix.asn.au mirror.selfnet.de HTTPS | RSYNC mirror.ufro.cl HTTPS | RSYNC Jonathan Guti\u00e9rrez mirror.yandex.ru HTTPS | RSYNC - mirrors.dotsrc.org HTTPS | RSYNC staff@dotsrc.org mirrors.tuna.tsinghua.edu.cn HTTPS | RSYNC - mirrors.ustc.edu.cn HTTPS | RSYNC lug@ustc.edu.cn mirror.nju.edu.cn HTTPS | RSYNC my@yaoge123.com","title":"Tier 1 Mirrors"},{"location":"dev/mirrors/#tier-2-mirrors","text":"Requirements: Synced regularly. Name URLs Contact Note downloads.sourceforge.net HTTPS contact fastmirror.pp.ua HTTPS | RSYNC smlr@ukr.net (too slow for T1) ftp.cc.uoc.gr HTTPS mirrors@cc.uoc.gr mirrors.bit.edu.cn HTTPS webmaster@bitnp.net mirror.jmu.edu HTTPS mirrormaster@jmu.edu mirrors.piconets.webwerks.in HTTPS mirrors@piconets.com mirrors.sjtug.sjtu.edu.cn HTTPS quantum-mirror.hu HTTPS | RSYNC root@quantum-mirror.hu (too slow for T1) www2.futureware.at HTTPS Nick \u00d8stergaard repo.casualgamer.ca HTTPS","title":"Tier 2 Mirrors"},{"location":"dev/mirrors/#adding-a-new-mirror","text":"The repository size is ~240 GiB (see https://mirror.jmu.edu/ for current stats) with the distribution of sizes like this: -1K: ~14000 files -100K: ~3200 files -1M: ~5000 files -10M: ~4000 files -100M: ~1000 files -1G: ~200 files -10G: ~20 files You can use rsync to update your mirror using rsync -rtlvH --delete-after --delay-updates --safe-links \\ rsync://repo.msys2.org/builds/ ./msys2 Our repository layout is compatible with Arch Linux, which means you can use the following script to sync everything more frequently and efficiently: https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/syncrepo/files/syncrepo-template.sh source_url = 'rsync://repo.msys2.org/builds/' lastupdate_url = 'https://repo.msys2.org/lastupdate' To register your mirror please open an issue here: https://github.com/msys2/msys2.github.io/issues","title":"Adding a New Mirror"},{"location":"dev/python/","text":"Python PKGBUILD: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python Source: https://github.com/msys2-contrib/cpython-mingw Major Version Upgrade Workflow Create a new branch at https://github.com/msys2-contrib/cpython-mingw for the new version Copy the existing PKGBUILD to a \"python3.x\" and set _primary_python=no Test the new version (Windows 7 support?) Maybe wait for 3.x.1 / 2 for the initial issues to be ironed out Figure out which packages need to be rebuild: Use https://github.com/jeremyd2019/package-grokker to detect dependencies on the .dll pacman -Fqx '/python3\\.9/' '.*\\.pyc' to detect the remaining packages Try to update packages that need to be rebuild to get potential Python related fixes. Move the PKGBUILD over to mingw-w64-python and make it the default one and rebuild all relevant packages Let autobuild handle the rest","title":"Python"},{"location":"dev/python/#python","text":"PKGBUILD: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python Source: https://github.com/msys2-contrib/cpython-mingw","title":"Python"},{"location":"dev/python/#major-version-upgrade-workflow","text":"Create a new branch at https://github.com/msys2-contrib/cpython-mingw for the new version Copy the existing PKGBUILD to a \"python3.x\" and set _primary_python=no Test the new version (Windows 7 support?) Maybe wait for 3.x.1 / 2 for the initial issues to be ironed out Figure out which packages need to be rebuild: Use https://github.com/jeremyd2019/package-grokker to detect dependencies on the .dll pacman -Fqx '/python3\\.9/' '.*\\.pyc' to detect the remaining packages Try to update packages that need to be rebuild to get potential Python related fixes. Move the PKGBUILD over to mingw-w64-python and make it the default one and rebuild all relevant packages Let autobuild handle the rest","title":"Major Version Upgrade Workflow"},{"location":"docs/ci/","text":"Using MSYS2 in CI Github Actions (recommended) Assuming you use GitHub this is the easiest way to get going. We provide a GitHub Action which handles everything from installing the latest MSYS2, updating it and installing all the packages you need. All you have to do is to provide a BASH script that runs your code in the MSYS2 environment. 1) Create a workflow file, see the GitHub docs for details 2) Paste the following into your workflow file: name : Hello World on : [ push , pull_request ] jobs : build : runs-on : windows-latest defaults : run : shell : msys2 {0} steps : - uses : actions/checkout@v2 - uses : msys2/setup-msys2@v2 with : msystem : MINGW64 update : true install : git mingw-w64-x86_64-toolchain - name : CI-Build run : | echo 'Running in MSYS2!' ./ci-build.sh For more details on the 'msys2/setup-msys2' action and all the available options see https://github.com/marketplace/actions/setup-msys2 Appveyor Appveyor provides a MSYS2 installation on all their images under C:\\msys64 , see https://www.appveyor.com/docs/windows-images-software/ In case you want to update the MSYS2 installation and install packages you need to update MSYS2 first. For this you need to run the following commands: # Update MSYS2 C :\\ msys64 \\ usr \\ bin \\ bash -lc \"pacman --noconfirm -Syuu\" # Core update (in case any core packages are outdated) C :\\ msys64 \\ usr \\ bin \\ bash -lc \"pacman --noconfirm -Syuu\" # Normal update # Then run your code $env:CHERE_INVOKING = 'yes' # Preserve the current working directory $env:MSYSTEM = 'MINGW64' # Start a 64 bit Mingw environment C :\\ msys64 \\ usr \\ bin \\ bash -lc \"./ci-build.sh\" Docker Install MSYS2 under C:\\msys64 into a Windows based Docker image: # select as base image matching your host to get process isolation FROM mcr.microsoft.com/windows/servercore:2004 SHELL [ \"powershell\" , \"-Command\" , \"$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';\" ] RUN [ Net.ServicePointManager ] ::SecurityProtocol = [ Net.SecurityProtocolType ] ::Tls12 ; \\ Invoke-WebRequest -UseBasicParsing -uri \"https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.sfx.exe\" -OutFile msys2.exe ; \\ . \\m sys2.exe -y -oC: \\; \\ Remove-Item msys2.exe ; \\ function msys () { C: \\m sys64 \\u sr \\b in \\b ash.exe @ ( '-lc' ) + @Args ; } \\ msys ' ' ; \\ msys 'pacman --noconfirm -Syuu' ; \\ msys 'pacman --noconfirm -Syuu' ; \\ msys 'pacman --noconfirm -Scc' ; Other Systems On systems that don't provide MSYS2 integration you need to install and update MSYS2 yourself. 1) Download and install MSYS2. For CI systems we provide a self extracting archive, so you don't need any additional tools. # Download the archive ( New-Object System . Net . WebClient ). DownloadFile ( 'https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.sfx.exe' , 'msys2.exe' ) .\\ msys2 . exe -y -oC :\\ # Extract to C:\\msys64 Remove-Item msys2 . exe # Delete the archive again 2) Run MSYS2 for the first time and update it # Run for the first time C :\\ msys64 \\ usr \\ bin \\ bash -lc ' ' # Update MSYS2 C :\\ msys64 \\ usr \\ bin \\ bash -lc 'pacman --noconfirm -Syuu' # Core update (in case any core packages are outdated) C :\\ msys64 \\ usr \\ bin \\ bash -lc 'pacman --noconfirm -Syuu' # Normal update 3) Run your code ( ci-build.sh in this case) $env:CHERE_INVOKING = 'yes' # Preserve the current working directory $env:MSYSTEM = 'MINGW64' # Start a 64 bit Mingw environment C :\\ msys64 \\ usr \\ bin \\ bash -lc './ci-build.sh' 4) End all processes that might have been started by the MSYS2 update/setup In some cases CI systems will wait until all processes you have started have also ended, but the MSYS2 setup and update might spawn processes for gnupg etc. that will stay around in the background forever. To end them all you can run: taskkill / F / FI \"MODULES eq msys-2.0.dll\"","title":"Using MSYS2 in CI"},{"location":"docs/ci/#using-msys2-in-ci","text":"","title":"Using MSYS2 in CI"},{"location":"docs/ci/#github-actions-recommended","text":"Assuming you use GitHub this is the easiest way to get going. We provide a GitHub Action which handles everything from installing the latest MSYS2, updating it and installing all the packages you need. All you have to do is to provide a BASH script that runs your code in the MSYS2 environment. 1) Create a workflow file, see the GitHub docs for details 2) Paste the following into your workflow file: name : Hello World on : [ push , pull_request ] jobs : build : runs-on : windows-latest defaults : run : shell : msys2 {0} steps : - uses : actions/checkout@v2 - uses : msys2/setup-msys2@v2 with : msystem : MINGW64 update : true install : git mingw-w64-x86_64-toolchain - name : CI-Build run : | echo 'Running in MSYS2!' ./ci-build.sh For more details on the 'msys2/setup-msys2' action and all the available options see https://github.com/marketplace/actions/setup-msys2","title":"Github Actions (recommended)"},{"location":"docs/ci/#appveyor","text":"Appveyor provides a MSYS2 installation on all their images under C:\\msys64 , see https://www.appveyor.com/docs/windows-images-software/ In case you want to update the MSYS2 installation and install packages you need to update MSYS2 first. For this you need to run the following commands: # Update MSYS2 C :\\ msys64 \\ usr \\ bin \\ bash -lc \"pacman --noconfirm -Syuu\" # Core update (in case any core packages are outdated) C :\\ msys64 \\ usr \\ bin \\ bash -lc \"pacman --noconfirm -Syuu\" # Normal update # Then run your code $env:CHERE_INVOKING = 'yes' # Preserve the current working directory $env:MSYSTEM = 'MINGW64' # Start a 64 bit Mingw environment C :\\ msys64 \\ usr \\ bin \\ bash -lc \"./ci-build.sh\"","title":"Appveyor"},{"location":"docs/ci/#docker","text":"Install MSYS2 under C:\\msys64 into a Windows based Docker image: # select as base image matching your host to get process isolation FROM mcr.microsoft.com/windows/servercore:2004 SHELL [ \"powershell\" , \"-Command\" , \"$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';\" ] RUN [ Net.ServicePointManager ] ::SecurityProtocol = [ Net.SecurityProtocolType ] ::Tls12 ; \\ Invoke-WebRequest -UseBasicParsing -uri \"https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.sfx.exe\" -OutFile msys2.exe ; \\ . \\m sys2.exe -y -oC: \\; \\ Remove-Item msys2.exe ; \\ function msys () { C: \\m sys64 \\u sr \\b in \\b ash.exe @ ( '-lc' ) + @Args ; } \\ msys ' ' ; \\ msys 'pacman --noconfirm -Syuu' ; \\ msys 'pacman --noconfirm -Syuu' ; \\ msys 'pacman --noconfirm -Scc' ;","title":"Docker"},{"location":"docs/ci/#other-systems","text":"On systems that don't provide MSYS2 integration you need to install and update MSYS2 yourself. 1) Download and install MSYS2. For CI systems we provide a self extracting archive, so you don't need any additional tools. # Download the archive ( New-Object System . Net . WebClient ). DownloadFile ( 'https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.sfx.exe' , 'msys2.exe' ) .\\ msys2 . exe -y -oC :\\ # Extract to C:\\msys64 Remove-Item msys2 . exe # Delete the archive again 2) Run MSYS2 for the first time and update it # Run for the first time C :\\ msys64 \\ usr \\ bin \\ bash -lc ' ' # Update MSYS2 C :\\ msys64 \\ usr \\ bin \\ bash -lc 'pacman --noconfirm -Syuu' # Core update (in case any core packages are outdated) C :\\ msys64 \\ usr \\ bin \\ bash -lc 'pacman --noconfirm -Syuu' # Normal update 3) Run your code ( ci-build.sh in this case) $env:CHERE_INVOKING = 'yes' # Preserve the current working directory $env:MSYSTEM = 'MINGW64' # Start a 64 bit Mingw environment C :\\ msys64 \\ usr \\ bin \\ bash -lc './ci-build.sh' 4) End all processes that might have been started by the MSYS2 update/setup In some cases CI systems will wait until all processes you have started have also ended, but the MSYS2 setup and update might spawn processes for gnupg etc. that will stay around in the background forever. To end them all you can run: taskkill / F / FI \"MODULES eq msys-2.0.dll\"","title":"Other Systems"},{"location":"docs/environments/","text":"Environments MSYS2 comes with different environments/subsystems and the first thing you have to decide is which one to use. The differences among the environments are mainly environment variables, default compilers/linkers, architecture, system libraries used etc. If you are unsure, go with MINGW64 . The MSYS environment contains the unix-like/cygwin based tools, lives under /usr and are special in that it is always active. All the other environments inherit from the MSYS environment and add various things on top of it. For example, in the MINGW64 environment the $PATH variable starts with /mingw64/bin:/usr/bin so you get all mingw64 based tools as well as all msys tools. Overview Name Prefix Toolchain Architecture C Library C++ Library MSYS /usr gcc x86_64 cygwin libstdc++ MINGW64 /mingw64 gcc x86_64 msvcrt libstdc++ UCRT64 /ucrt64 gcc x86_64 ucrt libstdc++ CLANG64 /clang64 llvm x86_64 ucrt libc++ MINGW32 /mingw32 gcc i686 msvcrt libstdc++ CLANG32 /clang32 llvm i686 ucrt libc++ GCC vs LLVM/Clang These are the default compilers/toolchains used for building all packages in the respective repositories. GCC based environments: Widely tested/used at this point Fortran support While there also exists a Clang package in the MINGW environments, that one still uses the GNU linker and the GNU C++ library. In some cases Clang is used to build packages as well there, in case upstream prefers Clang over GCC for example. LLVM/Clang based environments: Only uses LLVM tools, LLD as a linker, LIBC++ as a C++ standard library Clang provides ASAN support Native support for TLS (Thread-local storage) LLD is faster than LD, but does not support all the features LD supports Some tools lack feature parity with equivalent GNU tools Supports ARM64/AArch64 architecture on Microsoft Windows 10 MSVCRT vs UCRT These are two variants of the C standard library on Microsoft Windows. MSVCRT (Microsoft Visual C++ Runtime) is available by default on all Microsoft Windows versions, but due to backwards compatibility issues is stuck in the past, not C99 compatible and is missing some features. It isn't C99 compatible, for example the printf() function family, but... mingw-w64 provides replacement functions to make things C99 compatible in many cases It doesn't support the UTF-8 locale Binaries linked with MSVCRT should not be mixed with UCRT ones because the internal structures and data types are different. (More strictly, object files or static libraries built for different targets shouldn't be mixed. DLLs built for different CRTs can be mixed as long as they don't share CRT objects, e.g. FILE* , across DLL boundaries.) Same rule is applied for MSVC compiled binaries because MSVC uses UCRT by default (if not changed). Works out of the box on every Microsoft Windows versions. UCRT (Universal C Runtime) is a newer version which is also used by Microsoft Visual Studio by default. It should work and behave as if the code was compiled with MSVC. Better compatibility with MSVC, both at build time and at run time. It only ships by default on Windows 10 and for older versions you have to provide it yourself or depend on the user having it installed.","title":"Environments"},{"location":"docs/environments/#environments","text":"MSYS2 comes with different environments/subsystems and the first thing you have to decide is which one to use. The differences among the environments are mainly environment variables, default compilers/linkers, architecture, system libraries used etc. If you are unsure, go with MINGW64 . The MSYS environment contains the unix-like/cygwin based tools, lives under /usr and are special in that it is always active. All the other environments inherit from the MSYS environment and add various things on top of it. For example, in the MINGW64 environment the $PATH variable starts with /mingw64/bin:/usr/bin so you get all mingw64 based tools as well as all msys tools.","title":"Environments"},{"location":"docs/environments/#overview","text":"Name Prefix Toolchain Architecture C Library C++ Library MSYS /usr gcc x86_64 cygwin libstdc++ MINGW64 /mingw64 gcc x86_64 msvcrt libstdc++ UCRT64 /ucrt64 gcc x86_64 ucrt libstdc++ CLANG64 /clang64 llvm x86_64 ucrt libc++ MINGW32 /mingw32 gcc i686 msvcrt libstdc++ CLANG32 /clang32 llvm i686 ucrt libc++","title":"Overview"},{"location":"docs/environments/#gcc-vs-llvmclang","text":"These are the default compilers/toolchains used for building all packages in the respective repositories. GCC based environments: Widely tested/used at this point Fortran support While there also exists a Clang package in the MINGW environments, that one still uses the GNU linker and the GNU C++ library. In some cases Clang is used to build packages as well there, in case upstream prefers Clang over GCC for example. LLVM/Clang based environments: Only uses LLVM tools, LLD as a linker, LIBC++ as a C++ standard library Clang provides ASAN support Native support for TLS (Thread-local storage) LLD is faster than LD, but does not support all the features LD supports Some tools lack feature parity with equivalent GNU tools Supports ARM64/AArch64 architecture on Microsoft Windows 10","title":"GCC vs LLVM/Clang"},{"location":"docs/environments/#msvcrt-vs-ucrt","text":"These are two variants of the C standard library on Microsoft Windows. MSVCRT (Microsoft Visual C++ Runtime) is available by default on all Microsoft Windows versions, but due to backwards compatibility issues is stuck in the past, not C99 compatible and is missing some features. It isn't C99 compatible, for example the printf() function family, but... mingw-w64 provides replacement functions to make things C99 compatible in many cases It doesn't support the UTF-8 locale Binaries linked with MSVCRT should not be mixed with UCRT ones because the internal structures and data types are different. (More strictly, object files or static libraries built for different targets shouldn't be mixed. DLLs built for different CRTs can be mixed as long as they don't share CRT objects, e.g. FILE* , across DLL boundaries.) Same rule is applied for MSVC compiled binaries because MSVC uses UCRT by default (if not changed). Works out of the box on every Microsoft Windows versions. UCRT (Universal C Runtime) is a newer version which is also used by Microsoft Visual Studio by default. It should work and behave as if the code was compiled with MSVC. Better compatibility with MSVC, both at build time and at run time. It only ships by default on Windows 10 and for older versions you have to provide it yourself or depend on the user having it installed.","title":"MSVCRT vs UCRT"},{"location":"docs/filesystem-paths/","text":"Filesystem Paths Many of our build processes are made up of a mix of Cygwin tools (makepkg/bash for starters) and native Windows tools. When building things the paths of input and output files and directories are often communicated between them via process arguments or environment variables. The problem here is that those are in many cases not compatible: C:\\nope is not a valid Unix path and \\n might make problems when being interpreted as an escape sequence. C:/nope is slightly better, because, while it's not a valid Unix path, if it's just forwarded to some other Windows tools things might work out fine. /foo is both a valid Windows path (drive relative path evaluating to C:\\foo for example) and a valid Unix path, but resolves to a different path. Again, if it's just forwarded to some other Unix tool then things might work out fine. foo/bar.txt just works, relative to the current working directory, while foo\\bar.txt is only OK with native tools. Path lists, commonly used in environment variables like FOO=/foo:/bar also will never work, since paths are separated by ; on Windows and not : , similarly c:/foo could be interpreted as a Unix path list containing c and /foo when a path list is expected. The only solution here is to avoid mixing Unix/Cygwin and native tools outside of makepkg (preferred) or convert them when they get passed between the different programs. For the latter MSYS2 provides an automatic conversion that just works automatically in many cases. Manual Unix \u27f7 Windows Path Conversion MSYS2 ships the Cygwin tool cygpath by default which allows converting paths between the Unix format, Windows format, and mixed format, see cygpath --help for details. $ cygpath -u C: \\\\ foo /c/foo $ cygpath -m /mingw64/bin C:/msys64/mingw64/bin $ cygpath -w /mingw64/bin C: \\m sys64 \\m ingw64 \\b in Automatic Unix \u27f6 Windows Path Conversion Process Arguments When calling native executables from the context of Cygwin then all the arguments that look like Unix paths will get auto converted to Windows. For example when calling native Python from the context of bash: $ python3 -c \"import sys; print(sys.argv)\" --dir = /foo [ '-c' , '--dir=C:/msys64/foo' ] $ python3 -c \"import sys; print(sys.argv)\" --dir = /foo:/bla [ '-c' , '--dir=C:\\\\msys64\\\\foo;C:\\\\msys64\\\\bla' ] While this is helpful in many cases it's also not perfect and in corner cases converts arguments that look like Unix paths while they are not, or detects lists of Unix paths where there are none. For these cases you can exclude certain arguments via the MSYS2_ARG_CONV_EXCL environment variable: $ MSYS2_ARG_CONV_EXCL = '--dir=' python3 -c \"import sys; print(sys.argv)\" --dir = /foo [ '-c' , '--dir=/foo' ] MSYS2_ARG_CONV_EXCL can either be * to mean exclude everything, or a list of one ore more arguments prefixes separated by ; , like MSYS2_ARG_CONV_EXCL=--dir=;--bla=;/test . It matches the prefix against the whole argument string. Environment Variables Similar to process arguments, paths in environment variables get converted too: $ MYVAR = /foo python3 -c \"import os; print(os.environ['MYVAR'])\" C:/msys64/foo $ MYVAR = /foo:/bar python3 -c \"import os; print(os.environ['MYVAR'])\" C: \\m sys64 \\f oo ; C: \\m sys64 \\b ar You can disable the conversion with MSYS2_ENV_CONV_EXCL : $ MSYS2_ENV_CONV_EXCL='MYVAR' MYVAR=/foo python3 -c \"import os; print(os.environ['MYVAR'])\" /foo MSYS2_ENV_CONV_EXCL can either be * to mean exclude everything, or a list of one ore more environment variable prefixes separated by ; , like MSYS2_ENV_CONV_EXCL=FOO;BAR;/test . It matches the prefix against the following string KEY=VALUE . Cygwin special cases some environment variables that are known to be paths or path lists and does less guessing with them. For example HOME will never be interpreted as a path list even if it contains : . Windows \u27f6 Unix Path Conversion You might wonder why calling things like ls C:/ might work and suspect that again auto conversion is used, but that's not the case: $ /usr/bin/python3 -c \"import sys, os; print(sys.argv, os.listdir(sys.argv[1]))\" C:/ [ '-c' , 'C:/' ] [ '$Recycle.Bin' , '$SysReset' , ... ] Cygwin which provides the POSIX API will just forward the paths to the Windows API as is. This works as long as the tool does not try to interpret the path too much and just forwards it to the system API. If that doesn't work in your case you can use cygpath : $ /usr/bin/python3 -c \"import sys, os; print(sys.argv, os.listdir(sys.argv[1]))\" \" $( cygpath -u C:/ ) \" [ '-c' , '/c/' ] [ '$Recycle.Bin' , '$SysReset' , ... ] The package prefix (hack) When looking at some of our package recipes you might have seen something like: MSYS2_ARG_CONV_EXCL = \"--prefix=\" \\ meson \\ --prefix = \" ${ MINGW_PREFIX } \" \\ ... which results in meson --prefix=/mingw64 ... being executed. /mingw64 in this case is the UNIX prefix where the package will be installed to and in addition is a valid Windows path (a drive relative path, so C:\\mingw64 ), so the native build tools will concatenate it with DESTDIR and copy things to the right place. In the native Windows world this path doesn't make much sense, as C:\\mingw64 likely doesn't match where the software lives, but ideally all native Windows tools are relocatable and wont use the prefix at runtime anyway. And if they do and happen to call Cygwin tools then the prefix resolves to the correct path because the Cygwin root path is relocatable.","title":"Filesystem Paths"},{"location":"docs/filesystem-paths/#filesystem-paths","text":"Many of our build processes are made up of a mix of Cygwin tools (makepkg/bash for starters) and native Windows tools. When building things the paths of input and output files and directories are often communicated between them via process arguments or environment variables. The problem here is that those are in many cases not compatible: C:\\nope is not a valid Unix path and \\n might make problems when being interpreted as an escape sequence. C:/nope is slightly better, because, while it's not a valid Unix path, if it's just forwarded to some other Windows tools things might work out fine. /foo is both a valid Windows path (drive relative path evaluating to C:\\foo for example) and a valid Unix path, but resolves to a different path. Again, if it's just forwarded to some other Unix tool then things might work out fine. foo/bar.txt just works, relative to the current working directory, while foo\\bar.txt is only OK with native tools. Path lists, commonly used in environment variables like FOO=/foo:/bar also will never work, since paths are separated by ; on Windows and not : , similarly c:/foo could be interpreted as a Unix path list containing c and /foo when a path list is expected. The only solution here is to avoid mixing Unix/Cygwin and native tools outside of makepkg (preferred) or convert them when they get passed between the different programs. For the latter MSYS2 provides an automatic conversion that just works automatically in many cases.","title":"Filesystem Paths"},{"location":"docs/filesystem-paths/#manual-unix-windows-path-conversion","text":"MSYS2 ships the Cygwin tool cygpath by default which allows converting paths between the Unix format, Windows format, and mixed format, see cygpath --help for details. $ cygpath -u C: \\\\ foo /c/foo $ cygpath -m /mingw64/bin C:/msys64/mingw64/bin $ cygpath -w /mingw64/bin C: \\m sys64 \\m ingw64 \\b in","title":"Manual Unix \u27f7 Windows Path Conversion"},{"location":"docs/filesystem-paths/#automatic-unix-windows-path-conversion","text":"","title":"Automatic Unix \u27f6 Windows Path Conversion"},{"location":"docs/filesystem-paths/#process-arguments","text":"When calling native executables from the context of Cygwin then all the arguments that look like Unix paths will get auto converted to Windows. For example when calling native Python from the context of bash: $ python3 -c \"import sys; print(sys.argv)\" --dir = /foo [ '-c' , '--dir=C:/msys64/foo' ] $ python3 -c \"import sys; print(sys.argv)\" --dir = /foo:/bla [ '-c' , '--dir=C:\\\\msys64\\\\foo;C:\\\\msys64\\\\bla' ] While this is helpful in many cases it's also not perfect and in corner cases converts arguments that look like Unix paths while they are not, or detects lists of Unix paths where there are none. For these cases you can exclude certain arguments via the MSYS2_ARG_CONV_EXCL environment variable: $ MSYS2_ARG_CONV_EXCL = '--dir=' python3 -c \"import sys; print(sys.argv)\" --dir = /foo [ '-c' , '--dir=/foo' ] MSYS2_ARG_CONV_EXCL can either be * to mean exclude everything, or a list of one ore more arguments prefixes separated by ; , like MSYS2_ARG_CONV_EXCL=--dir=;--bla=;/test . It matches the prefix against the whole argument string.","title":"Process Arguments"},{"location":"docs/filesystem-paths/#environment-variables","text":"Similar to process arguments, paths in environment variables get converted too: $ MYVAR = /foo python3 -c \"import os; print(os.environ['MYVAR'])\" C:/msys64/foo $ MYVAR = /foo:/bar python3 -c \"import os; print(os.environ['MYVAR'])\" C: \\m sys64 \\f oo ; C: \\m sys64 \\b ar You can disable the conversion with MSYS2_ENV_CONV_EXCL : $ MSYS2_ENV_CONV_EXCL='MYVAR' MYVAR=/foo python3 -c \"import os; print(os.environ['MYVAR'])\" /foo MSYS2_ENV_CONV_EXCL can either be * to mean exclude everything, or a list of one ore more environment variable prefixes separated by ; , like MSYS2_ENV_CONV_EXCL=FOO;BAR;/test . It matches the prefix against the following string KEY=VALUE . Cygwin special cases some environment variables that are known to be paths or path lists and does less guessing with them. For example HOME will never be interpreted as a path list even if it contains : .","title":"Environment Variables"},{"location":"docs/filesystem-paths/#windows-unix-path-conversion","text":"You might wonder why calling things like ls C:/ might work and suspect that again auto conversion is used, but that's not the case: $ /usr/bin/python3 -c \"import sys, os; print(sys.argv, os.listdir(sys.argv[1]))\" C:/ [ '-c' , 'C:/' ] [ '$Recycle.Bin' , '$SysReset' , ... ] Cygwin which provides the POSIX API will just forward the paths to the Windows API as is. This works as long as the tool does not try to interpret the path too much and just forwards it to the system API. If that doesn't work in your case you can use cygpath : $ /usr/bin/python3 -c \"import sys, os; print(sys.argv, os.listdir(sys.argv[1]))\" \" $( cygpath -u C:/ ) \" [ '-c' , '/c/' ] [ '$Recycle.Bin' , '$SysReset' , ... ]","title":"Windows \u27f6 Unix Path Conversion"},{"location":"docs/filesystem-paths/#the-package-prefix-hack","text":"When looking at some of our package recipes you might have seen something like: MSYS2_ARG_CONV_EXCL = \"--prefix=\" \\ meson \\ --prefix = \" ${ MINGW_PREFIX } \" \\ ... which results in meson --prefix=/mingw64 ... being executed. /mingw64 in this case is the UNIX prefix where the package will be installed to and in addition is a valid Windows path (a drive relative path, so C:\\mingw64 ), so the native build tools will concatenate it with DESTDIR and copy things to the right place. In the native Windows world this path doesn't make much sense, as C:\\mingw64 likely doesn't match where the software lives, but ideally all native Windows tools are relocatable and wont use the prefix at runtime anyway. And if they do and happen to call Cygwin tools then the prefix resolves to the correct path because the Cygwin root path is relocatable.","title":"The package prefix (hack)"},{"location":"docs/package-management/","text":"Package repositories The MSYS2 software distribution uses a port of pacman (known from Arch Linux) to manage (install, remove and update) binary packages and also to build those packages in the first place. Packages in MSYS2 work like packages in popular Linux distributions. A package is an archive containing a piece of software. This normally means executable files, runtime libraries, data, shared and static link libraries, header files, config files, and manual pages. Packages also contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum, and a list of dependencies necessary for the software to run properly. Upon installation, the files contained are extracted into your MSYS2 installation directory and the metadata are stored in a local database. There are 3 package repositories, msys2 , mingw32 , and mingw64 . The packages in msys2 are named just like on a Linux distribution, the packages in mingw are prefixed by either mingw-w64-i686- for 32-bit packages, or mingw-w64-x86_64- for 64-bit packages. Finding a package If you want to find a specific package in the repository (and that package can or cannot be installed on your machine) you can use the following command: pacman -Ss <name or part of the name of the package> Example: $ pacman -Ss openjp mingw32 / mingw - w64 - i686 - openjpeg 1.5.2 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw32 / mingw - w64 - i686 - openjpeg2 2.1.0 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw64 / mingw - w64 - x86_64 - openjpeg 1.5.2 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw64 / mingw - w64 - x86_64 - openjpeg2 2.1.0 - 7 [ installed ] An open source JPEG 2000 codec ( mingw - w64 ) As you can see the mingw-w64-x86_64-openjpeg2 package is installed, while the mingw-w64-x86_64-openjpeg package is not installed. If you would like to search only among the packages which has been already installed, use the following command: pacman -Qs <name or part of the name of the package> Installing a package If you wan to install a package, use the following command: pacman -S <name of the package> If the package has dependencies which are not installed, pacman will ask you whether you would like to install the dependencies in the first place. pacman -S also accepts virtual package names and package group names. Virtual package names can be often encountered with packages built from Git, e.g. msys2-launcher-git can be installed by requesting msys-launcher . Package groups simplify installation of related packages, e.g. install base-devel to get basic development tools. Please note that neither of those are real packages, so the commands below won't accept these names and you need to use the real package names instead. Uninstalling a package The following command will remove a package (but not its dependencies nor any files produced by running it): pacman -R <name of the package> Installing a specific version of a package or a stand-alone packages Older (or pre-release) versions of packages can be installed directly from the package archive ( .tar.zst or .tar.xz ). The data store for the repositories contains older versions of packages, but beware that you might need to recursively find correct versions of dependencies for the desired package. Once downloaded, the package can be installed like this: pacman -U <packagefile.tar.zst> or pacman -U <packagefile.tar.xz> Listing the content of a package If you would like to know what has been installed as a part of a specific package use the following command: pacman -Ql <name of the package> Example: $ pacman -Ql mingw-w64-x86_64-pugixml mingw-w64-x86_64-pugixml /mingw64/ mingw-w64-x86_64-pugixml /mingw64/bin/ mingw-w64-x86_64-pugixml /mingw64/bin/libpugixml.dll mingw-w64-x86_64-pugixml /mingw64/include/ mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/ mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/pugiconfig.hpp mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/pugixml.hpp mingw-w64-x86_64-pugixml /mingw64/lib/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/pugixml-config-noconfig.cmake mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/pugixml-config.cmake mingw-w64-x86_64-pugixml /mingw64/lib/pkgconfig/ mingw-w64-x86_64-pugixml /mingw64/lib/pkgconfig/pugixml.pc mingw-w64-x86_64-pugixml /mingw64/lib/pugixml-1.8/ mingw-w64-x86_64-pugixml /mingw64/lib/pugixml-1.8/libpugixml.dll.a As you can see the package contains: a binary executable library file (libpugixml.dll), a static library (libpugixml.dll.a), 2 header files (pugixml.hpp, pugiconfig.hpp), 2 cmake files, and a PKGCONFIG file (pugixml.pc). Finding dependencies of a package You can use pactree to figure out which packages are needed to make a package working properly: $ pactree mingw-w64-x86_64-gettext mingw-w64-x86_64-gettext \u251c\u2500mingw-w64-x86_64-expat \u251c\u2500mingw-w64-x86_64-gcc-libs \u2502 \u251c\u2500mingw-w64-x86_64-gmp \u2502 \u251c\u2500mingw-w64-x86_64-libwinpthread-git provides mingw-w64-x86_64-libwinpthread \u2502 \u2514\u2500mingw-w64-x86_64-gcc-libgfortran \u2502 \u2514\u2500mingw-w64-x86_64-gcc-libs \u2514\u2500mingw-w64-x86_64-libiconv Alternatively you can use pacman -Qi to get the list of direct dependencies of a package: $ pacman -Qi mingw-w64-x86_64-gettext Name : mingw-w64-x86_64-gettext Version : 0.19.7-1 Description : GNU internationalization library (mingw-w64) [...] Depends On : mingw-w64-x86_64-expat mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-libiconv Finding out which package a file belongs to Use the following command to trace a file back to its owning package: pacman -Qo <full file path> Note that this operation only compares the file paths, so proper capitalization and the .exe suffix (if applicable) is required. Also note that this works only on installed packages, it will not scan the whole package repositories. Finding which package will install the file you need The two recommended tools that can scan a repository and find packages that contain specific files are pacman -F and pkgfile . Below are examples of pacman -F usage: Call pacman -Fy to update your package database. To find an exact match, call pacman -F <filename> (don't include the path in the filename). To find a substring match, call pacman -Fx <filename> . Note that this operation only compares the file paths, so proper capitalization and the .exe suffix (if applicable) is required. Avoiding writing long package names Use pacboy to install mingw packages without having to type the long package names (install pacboy first using pacman -S pactoys if necessary). Examples: $ pacboy -S x265:x resolving dependencies... looking for conflicting packages... Packages (1) mingw-w64-x86_64-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 20.72 MiB :: Proceed with installation? [Y/n] $ pacboy -S x265:i resolving dependencies... looking for conflicting packages... Packages (1) mingw-w64-i686-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 11.37 MiB :: Proceed with installation? [Y/n] $ pacboy -S x265:m resolving dependencies... looking for conflicting packages... Packages (2) mingw-w64-i686-x265-2.3-1 mingw-w64-x86_64-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 32.09 MiB :: Proceed with installation? [Y/n] Resources Pacman on ArchWiki Pacman tips on ArchWiki","title":"Package Management"},{"location":"docs/package-management/#package-repositories","text":"The MSYS2 software distribution uses a port of pacman (known from Arch Linux) to manage (install, remove and update) binary packages and also to build those packages in the first place. Packages in MSYS2 work like packages in popular Linux distributions. A package is an archive containing a piece of software. This normally means executable files, runtime libraries, data, shared and static link libraries, header files, config files, and manual pages. Packages also contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum, and a list of dependencies necessary for the software to run properly. Upon installation, the files contained are extracted into your MSYS2 installation directory and the metadata are stored in a local database. There are 3 package repositories, msys2 , mingw32 , and mingw64 . The packages in msys2 are named just like on a Linux distribution, the packages in mingw are prefixed by either mingw-w64-i686- for 32-bit packages, or mingw-w64-x86_64- for 64-bit packages.","title":"Package repositories"},{"location":"docs/package-management/#finding-a-package","text":"If you want to find a specific package in the repository (and that package can or cannot be installed on your machine) you can use the following command: pacman -Ss <name or part of the name of the package> Example: $ pacman -Ss openjp mingw32 / mingw - w64 - i686 - openjpeg 1.5.2 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw32 / mingw - w64 - i686 - openjpeg2 2.1.0 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw64 / mingw - w64 - x86_64 - openjpeg 1.5.2 - 7 An open source JPEG 2000 codec ( mingw - w64 ) mingw64 / mingw - w64 - x86_64 - openjpeg2 2.1.0 - 7 [ installed ] An open source JPEG 2000 codec ( mingw - w64 ) As you can see the mingw-w64-x86_64-openjpeg2 package is installed, while the mingw-w64-x86_64-openjpeg package is not installed. If you would like to search only among the packages which has been already installed, use the following command: pacman -Qs <name or part of the name of the package>","title":"Finding a package"},{"location":"docs/package-management/#installing-a-package","text":"If you wan to install a package, use the following command: pacman -S <name of the package> If the package has dependencies which are not installed, pacman will ask you whether you would like to install the dependencies in the first place. pacman -S also accepts virtual package names and package group names. Virtual package names can be often encountered with packages built from Git, e.g. msys2-launcher-git can be installed by requesting msys-launcher . Package groups simplify installation of related packages, e.g. install base-devel to get basic development tools. Please note that neither of those are real packages, so the commands below won't accept these names and you need to use the real package names instead.","title":"Installing a package"},{"location":"docs/package-management/#uninstalling-a-package","text":"The following command will remove a package (but not its dependencies nor any files produced by running it): pacman -R <name of the package>","title":"Uninstalling a package"},{"location":"docs/package-management/#installing-a-specific-version-of-a-package-or-a-stand-alone-packages","text":"Older (or pre-release) versions of packages can be installed directly from the package archive ( .tar.zst or .tar.xz ). The data store for the repositories contains older versions of packages, but beware that you might need to recursively find correct versions of dependencies for the desired package. Once downloaded, the package can be installed like this: pacman -U <packagefile.tar.zst> or pacman -U <packagefile.tar.xz>","title":"Installing a specific version of a package or a stand-alone packages"},{"location":"docs/package-management/#listing-the-content-of-a-package","text":"If you would like to know what has been installed as a part of a specific package use the following command: pacman -Ql <name of the package> Example: $ pacman -Ql mingw-w64-x86_64-pugixml mingw-w64-x86_64-pugixml /mingw64/ mingw-w64-x86_64-pugixml /mingw64/bin/ mingw-w64-x86_64-pugixml /mingw64/bin/libpugixml.dll mingw-w64-x86_64-pugixml /mingw64/include/ mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/ mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/pugiconfig.hpp mingw-w64-x86_64-pugixml /mingw64/include/pugixml-1.8/pugixml.hpp mingw-w64-x86_64-pugixml /mingw64/lib/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/ mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/pugixml-config-noconfig.cmake mingw-w64-x86_64-pugixml /mingw64/lib/cmake/pugixml/pugixml-config.cmake mingw-w64-x86_64-pugixml /mingw64/lib/pkgconfig/ mingw-w64-x86_64-pugixml /mingw64/lib/pkgconfig/pugixml.pc mingw-w64-x86_64-pugixml /mingw64/lib/pugixml-1.8/ mingw-w64-x86_64-pugixml /mingw64/lib/pugixml-1.8/libpugixml.dll.a As you can see the package contains: a binary executable library file (libpugixml.dll), a static library (libpugixml.dll.a), 2 header files (pugixml.hpp, pugiconfig.hpp), 2 cmake files, and a PKGCONFIG file (pugixml.pc).","title":"Listing the content of a package"},{"location":"docs/package-management/#finding-dependencies-of-a-package","text":"You can use pactree to figure out which packages are needed to make a package working properly: $ pactree mingw-w64-x86_64-gettext mingw-w64-x86_64-gettext \u251c\u2500mingw-w64-x86_64-expat \u251c\u2500mingw-w64-x86_64-gcc-libs \u2502 \u251c\u2500mingw-w64-x86_64-gmp \u2502 \u251c\u2500mingw-w64-x86_64-libwinpthread-git provides mingw-w64-x86_64-libwinpthread \u2502 \u2514\u2500mingw-w64-x86_64-gcc-libgfortran \u2502 \u2514\u2500mingw-w64-x86_64-gcc-libs \u2514\u2500mingw-w64-x86_64-libiconv Alternatively you can use pacman -Qi to get the list of direct dependencies of a package: $ pacman -Qi mingw-w64-x86_64-gettext Name : mingw-w64-x86_64-gettext Version : 0.19.7-1 Description : GNU internationalization library (mingw-w64) [...] Depends On : mingw-w64-x86_64-expat mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-libiconv","title":"Finding dependencies of a package"},{"location":"docs/package-management/#finding-out-which-package-a-file-belongs-to","text":"Use the following command to trace a file back to its owning package: pacman -Qo <full file path> Note that this operation only compares the file paths, so proper capitalization and the .exe suffix (if applicable) is required. Also note that this works only on installed packages, it will not scan the whole package repositories.","title":"Finding out which package a file belongs to"},{"location":"docs/package-management/#finding-which-package-will-install-the-file-you-need","text":"The two recommended tools that can scan a repository and find packages that contain specific files are pacman -F and pkgfile . Below are examples of pacman -F usage: Call pacman -Fy to update your package database. To find an exact match, call pacman -F <filename> (don't include the path in the filename). To find a substring match, call pacman -Fx <filename> . Note that this operation only compares the file paths, so proper capitalization and the .exe suffix (if applicable) is required.","title":"Finding which package will install the file you need"},{"location":"docs/package-management/#avoiding-writing-long-package-names","text":"Use pacboy to install mingw packages without having to type the long package names (install pacboy first using pacman -S pactoys if necessary). Examples: $ pacboy -S x265:x resolving dependencies... looking for conflicting packages... Packages (1) mingw-w64-x86_64-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 20.72 MiB :: Proceed with installation? [Y/n] $ pacboy -S x265:i resolving dependencies... looking for conflicting packages... Packages (1) mingw-w64-i686-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 11.37 MiB :: Proceed with installation? [Y/n] $ pacboy -S x265:m resolving dependencies... looking for conflicting packages... Packages (2) mingw-w64-i686-x265-2.3-1 mingw-w64-x86_64-x265-2.3-1 Total Download Size: 0.97 MiB Total Installed Size: 32.09 MiB :: Proceed with installation? [Y/n]","title":"Avoiding writing long package names"},{"location":"docs/package-management/#resources","text":"Pacman on ArchWiki Pacman tips on ArchWiki","title":"Resources"},{"location":"docs/terminals/","text":"Terminals Mintty Mintty is the default terminal application in MSYS2 and is included in the installer. We also include some custom Mintty integration by providing separate launchers with corresponding .ini configuration files (msys2{.exe,.ini}/mingw32{.exe,.ini}/mingw64{.exe,.ini}) for all the MSYS2 environments, so you can easily configure your environments and pin the launchers to your Windows taskbar. See https://github.com/msys2/msys2-launcher and https://mintty.github.io for more details. Windows Terminal The new Windows Terminal application, which by default supports cmd, powershell and WSL can also be extended to support a MSYS2 shell. Get it via the Windows app store if you don't have it installed already. In the tab dropdown menu select \"Settings\" which opens a code editor showing a JSON configuration file. Insert the example profiles shown below under the profiles key. Note that the examples assume that you have MSYS2 installed under C:\\msys64 . You can make one of the MSYS2 profiles the default by setting the defaultProfile key to the guid value of one of the profile entries. For more info on the different profile settings see https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-settings // This makes MINGW 64 t he de fault shell \"defaultProfile\" : \"{17da3cac-b318-431e-8a3e-7fcdefe6d114}\" , \"profiles\" : { \"list\" : [ // ... { \"guid\" : \"{17da3cac-b318-431e-8a3e-7fcdefe6d114}\" , \"name\" : \"MINGW64 / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw64\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/mingw64.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, { \"guid\" : \"{2d51fdc4-a03b-4efe-81bc-722b7f6f3820}\" , \"name\" : \"MINGW32 / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw32\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/mingw32.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, { \"guid\" : \"{71160544-14d8-4194-af25-d05feeac7233}\" , \"name\" : \"MSYS / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -msys\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/msys2.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, // ... ] }","title":"Terminals"},{"location":"docs/terminals/#terminals","text":"","title":"Terminals"},{"location":"docs/terminals/#mintty","text":"Mintty is the default terminal application in MSYS2 and is included in the installer. We also include some custom Mintty integration by providing separate launchers with corresponding .ini configuration files (msys2{.exe,.ini}/mingw32{.exe,.ini}/mingw64{.exe,.ini}) for all the MSYS2 environments, so you can easily configure your environments and pin the launchers to your Windows taskbar. See https://github.com/msys2/msys2-launcher and https://mintty.github.io for more details.","title":"Mintty"},{"location":"docs/terminals/#windows-terminal","text":"The new Windows Terminal application, which by default supports cmd, powershell and WSL can also be extended to support a MSYS2 shell. Get it via the Windows app store if you don't have it installed already. In the tab dropdown menu select \"Settings\" which opens a code editor showing a JSON configuration file. Insert the example profiles shown below under the profiles key. Note that the examples assume that you have MSYS2 installed under C:\\msys64 . You can make one of the MSYS2 profiles the default by setting the defaultProfile key to the guid value of one of the profile entries. For more info on the different profile settings see https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-settings // This makes MINGW 64 t he de fault shell \"defaultProfile\" : \"{17da3cac-b318-431e-8a3e-7fcdefe6d114}\" , \"profiles\" : { \"list\" : [ // ... { \"guid\" : \"{17da3cac-b318-431e-8a3e-7fcdefe6d114}\" , \"name\" : \"MINGW64 / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw64\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/mingw64.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, { \"guid\" : \"{2d51fdc4-a03b-4efe-81bc-722b7f6f3820}\" , \"name\" : \"MINGW32 / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw32\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/mingw32.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, { \"guid\" : \"{71160544-14d8-4194-af25-d05feeac7233}\" , \"name\" : \"MSYS / MSYS2\" , \"commandline\" : \"C:/msys64/msys2_shell.cmd -defterm -here -no-start -msys\" , \"startingDirectory\" : \"C:/msys64/home/%USERNAME%\" , \"icon\" : \"C:/msys64/msys2.ico\" , \"fontFace\" : \"Lucida Console\" , \"fontSize\" : 9 }, // ... ] }","title":"Windows Terminal"},{"location":"docs/what-is-msys2/","text":"What is MSYS2? MSYS2 isn't \"one tool to rule them all\", but tries to focus on what it's good at. It provides a native build environment, based on open source software, and makes you feel right at home when you are already comfortable with Linux. There are good reasons to use multiple different environments and tools for different tasks on Windows. MSYS2 vs Other Projects In case you'd like to see more comparisons or feel that they could be improved please let us know. MSYS2 vs WSL MSYS2 allows you to build native Windows programs, while with WSL you can only cross compile them which makes things more complicated. If you are just looking for Linux CLI tools, or want to build software that ends up on a Linux server anyway then WSL is the better choice. MSYS2 vs Chocolatey Chocolatey mainly bundles already built (open and closed source) software and makes it easy to install/update them. In MSYS2 on the other hand all packages are built from source and you can easily reproduce the builds on your machine. Chocolatey packages have the advantage that the bundled installers usually have better Windows integration, in that they set up file associations, shortcuts, etc. and because they are not built from source there are also lots of packages for closed source software like Visual Studio etc. that would be hard to manage/update otherwise. MSYS2 vs Cygwin The unixy tools in MSYS2 are directly based on Cygwin , so there is some overlap there. While Cygwin focuses on building Unix software on Windows as is, MSYS2 focuses on building native software built against the Windows APIs. MSYS2 vs Arch Linux MSYS2 and Arch Linux share the package manager and all that comes with it, like build definitions, rules for how to package things, how updates work, how packages are signed, how packages are shipped, the rolling release nature and so on. By re-using this functionality and concepts we can focus on the actual packages and profit from the experience and work of Arch Linux developers. Users already familiar with Arch Linux will also have an easier time getting started. MSYS2 vs Scoop Due to lack of experience with scoop see their comparison page: https://github.com/lukesampson/scoop/wiki/Chocolatey-Comparison https://github.com/lukesampson/scoop/wiki/Cygwin-and-MSYS-Comparison","title":"What is MSYS2?"},{"location":"docs/what-is-msys2/#what-is-msys2","text":"MSYS2 isn't \"one tool to rule them all\", but tries to focus on what it's good at. It provides a native build environment, based on open source software, and makes you feel right at home when you are already comfortable with Linux. There are good reasons to use multiple different environments and tools for different tasks on Windows.","title":"What is MSYS2?"},{"location":"docs/what-is-msys2/#msys2-vs-other-projects","text":"In case you'd like to see more comparisons or feel that they could be improved please let us know.","title":"MSYS2 vs Other Projects"},{"location":"docs/what-is-msys2/#msys2-vs-wsl","text":"MSYS2 allows you to build native Windows programs, while with WSL you can only cross compile them which makes things more complicated. If you are just looking for Linux CLI tools, or want to build software that ends up on a Linux server anyway then WSL is the better choice.","title":"MSYS2 vs WSL"},{"location":"docs/what-is-msys2/#msys2-vs-chocolatey","text":"Chocolatey mainly bundles already built (open and closed source) software and makes it easy to install/update them. In MSYS2 on the other hand all packages are built from source and you can easily reproduce the builds on your machine. Chocolatey packages have the advantage that the bundled installers usually have better Windows integration, in that they set up file associations, shortcuts, etc. and because they are not built from source there are also lots of packages for closed source software like Visual Studio etc. that would be hard to manage/update otherwise.","title":"MSYS2 vs Chocolatey"},{"location":"docs/what-is-msys2/#msys2-vs-cygwin","text":"The unixy tools in MSYS2 are directly based on Cygwin , so there is some overlap there. While Cygwin focuses on building Unix software on Windows as is, MSYS2 focuses on building native software built against the Windows APIs.","title":"MSYS2 vs Cygwin"},{"location":"docs/what-is-msys2/#msys2-vs-arch-linux","text":"MSYS2 and Arch Linux share the package manager and all that comes with it, like build definitions, rules for how to package things, how updates work, how packages are signed, how packages are shipped, the rolling release nature and so on. By re-using this functionality and concepts we can focus on the actual packages and profit from the experience and work of Arch Linux developers. Users already familiar with Arch Linux will also have an easier time getting started.","title":"MSYS2 vs Arch Linux"},{"location":"docs/what-is-msys2/#msys2-vs-scoop","text":"Due to lack of experience with scoop see their comparison page: https://github.com/lukesampson/scoop/wiki/Chocolatey-Comparison https://github.com/lukesampson/scoop/wiki/Cygwin-and-MSYS-Comparison","title":"MSYS2 vs Scoop"},{"location":"docs/who-is-using-msys2/","text":"Who Is Using MSYS2? Gaphor uses MSYS2 for its Windows releases and for CI Git for Windows is based on MSYS2 Quod Libet uses MSYS2 for its Windows build and for CI HDL/MINGW-packages uses MSYS2 for building and testing open source Electronic Design Automation (EDA) tools. ghdl/ghdl uses MSYS2 for building, packaging and testing GHDL. ghdl/setup-ghdl-ci uses setup-msys2 for users to run GHDL on GitHub Actions' Windows environments. ghdl/extended-tests uses setup-msys2 and setup-ghdl-ci for testing third-party projects with GHDL on GitHub Actions' Windows environments. gtkwave/gtkwave uses MSYS2 for building and packaging GTKWave. steveicarus/iverilog uses MSYS2 for building, packaging and testing Icarus Verilog. trabucayre/openFPGALoader uses MSYS2 for building, packaging and testing openFPGALoader. azonenberg/scopehal-apps uses MSYS2 for building libscopehal, glscopeclient and other client applications for libscopehal. Serial-Studio/Serial-Studio uses MSYS2 for building and testing Serial Studio. VUnit/vunit uses MSYS2 for testing VUnit. Inkscape uses MSYS2 for its Windows releases and for CI ( Documentation ) KeePassXC uses MSYS2 for building and running KeePassXC password manager. Media-autobuild_suite uses MSYS2 for automatically building FFmpeg and other media related tools Nuwen's MinGW Build uses MSYS2 to build the files. OpenModelica uses MSYS2 for building the OpenModelica tools and compiling the generated simulation code on Windows. Paperwork uses MSYS2 for its Windows releases and for CI ( Documentation ) The R Project build system rtools40 is based on MSYS2 icw/ a custom repository of mingw packages (all statically linked). UrusStudio Installer uses MSYS2 for building and running Urus Studio IDE and URUS System. Webots uses MSYS2 to build Webots on Windows and for CI. Feel free to add your project to this list!","title":"Who Is Using MSYS2?"},{"location":"docs/who-is-using-msys2/#who-is-using-msys2","text":"Gaphor uses MSYS2 for its Windows releases and for CI Git for Windows is based on MSYS2 Quod Libet uses MSYS2 for its Windows build and for CI HDL/MINGW-packages uses MSYS2 for building and testing open source Electronic Design Automation (EDA) tools. ghdl/ghdl uses MSYS2 for building, packaging and testing GHDL. ghdl/setup-ghdl-ci uses setup-msys2 for users to run GHDL on GitHub Actions' Windows environments. ghdl/extended-tests uses setup-msys2 and setup-ghdl-ci for testing third-party projects with GHDL on GitHub Actions' Windows environments. gtkwave/gtkwave uses MSYS2 for building and packaging GTKWave. steveicarus/iverilog uses MSYS2 for building, packaging and testing Icarus Verilog. trabucayre/openFPGALoader uses MSYS2 for building, packaging and testing openFPGALoader. azonenberg/scopehal-apps uses MSYS2 for building libscopehal, glscopeclient and other client applications for libscopehal. Serial-Studio/Serial-Studio uses MSYS2 for building and testing Serial Studio. VUnit/vunit uses MSYS2 for testing VUnit. Inkscape uses MSYS2 for its Windows releases and for CI ( Documentation ) KeePassXC uses MSYS2 for building and running KeePassXC password manager. Media-autobuild_suite uses MSYS2 for automatically building FFmpeg and other media related tools Nuwen's MinGW Build uses MSYS2 to build the files. OpenModelica uses MSYS2 for building the OpenModelica tools and compiling the generated simulation code on Windows. Paperwork uses MSYS2 for its Windows releases and for CI ( Documentation ) The R Project build system rtools40 is based on MSYS2 icw/ a custom repository of mingw packages (all statically linked). UrusStudio Installer uses MSYS2 for building and running Urus Studio IDE and URUS System. Webots uses MSYS2 to build Webots on Windows and for CI. Feel free to add your project to this list!","title":"Who Is Using MSYS2?"},{"location":"wiki/Contributing-to-MSYS2/","text":"Hi. If you're interested in helping the MSYS2 project, we will appreciate it. Please come to our IRC channel #msys2 on OFTC or Gitter room or Discord Server and talk to us. Don't be discouraged if nobody responds straight away, people are often busy or asleep. How can you help: prepare and maintain packages help other users spread the word use MSYS2 for your projects report bugs fix bugs upstream patches improve core packages write documentation help with organization or infrastructure provide mirrors donate","title":"Contributing to MSYS2"},{"location":"wiki/Creating-Packages/","text":"The MSYS2 software distribution uses a port of Pacman (known from Arch Linux) to safely install, remove and update binary packages and also to build those packages in the first place. General information There are 3 package repositories, msys , mingw32 , and mingw64 . msys software (from the msys repository) is software that depends on msys-2.0.dll and is very similar to Cygwin software (which is a POSIX emulation layer for Windows). Native Windows software (from this project's perspective) is software that doesn't depend on msys-2.0.dll , and links dynamically to the highly compatible msvcrt.dll . In this document, to attempt to avoid confusion, MSYS2 refers to the software distribution while msys refers to the repository, the packages in that repository and the software in those packages that link to msys-2.0.dll . Package recipes Packages are built from programmatic recipes to ensure builds are reproducible. A recipe is a set of files which describe how to build, package and install a given piece of software; these are often specific to MSYS2. In the simplest form it is a single file named PKGBUILD , which contains metadata for the package, a specification where the source for the given software can be found, and a few lines of code which that takes the source and builds the final software from it. For more complex cases it also contains install scripts or a number of patch files which are needed to be applied on the released version of the upstream software in order to be able to compile and work in the given environment. Typically, each recipe is in its own directory. The directory is also used when building as a working place by default. PKGBUILD Use 2 spaces for indentation: expand -t 2 PKGBUILD > PKGBUILD.new && mv PKGBUILD.new PKGBUILD A PKGBUILD is a bash script defining variables and functions that are then used by the build system to create the package. The PKGBUILD manpage and the PKGBUILD wikipage on ArchWiki are good sources to read about all the details of PKGBUILDs. The mingw PKGBUILDs are loosely based on the mingw-w64 cross-compilation packages guidelines in Arch Linux . If you don't want to read all that just yet, just read some existing PKGBUILDs; the purpose of most parts should be obvious. Patch files When creating a patch file, you can use the following naming convention for its name: ###-target-Purpose.patch Where ### a sequence number, starting from 001 target , is the package name and version (separated by a hyphen) for which the patch was first created [Purpose] describes what the patch is fixing or improving Building The actual build and packaging is done by running makepkg or makepkg-mingw . The former is used to build msys packages and the latter for mingw packages. To learn more, read the makepkg manpage and the makepkg wikipage on ArchWiki . When building either msys or native software, you should use the MSYS shell, not the MINGW{32,64} shells. The process happens in multiple phases: download, verify and extract - the package sources are downloaded if necessary, checked against checksums and PGP signatures if specified, and extracted into a working directory ( src by default) prepare() - using this function, the packager can specify what should happen with the sources before the actual build; apply patches and source modifications here build() - this function contains commands to run the build tool(s), e.g. ./configure and make check() - an optional step to check the build products by e.g. running the software's test suite package() - this function is provided with a temporary directory, where it should put the final contents of the package using e.g. make install tidy, archive and sign - the package contents are scanned for some issues, tidied up and packaged into the final .tar.zst with an optional signature in .tar.zst.sig The makepkg tool takes arguments allowing you to turn off some phases or some checks. The typical usage is makepkg -sCLf for a full build and makepkg -RdLf for a \"re-package\". Re-packaging is useful when the process failed in package() and you don't want to run the long build part again. makepkg-mingw takes the same arguments. Re-building a package To get you started, you can try just re-building an existing package. This may also be helpful if you need to diagnose an issue and need the debugging symbols. An example of fetching the msys repository source, building and then installing a package from it is: git clone \"https://github.com/msys2/MSYS2-packages\" cd MSYS2-packages/flex makepkg -sCLf pacman -U flex-*.pkg.tar.zst An example of fetching the mingw repository source, building and then installing a package from it is: git clone \"https://github.com/msys2/MINGW-packages\" cd MINGW-packages/mingw-w64-python3 makepkg-mingw -sCLf pacman -U mingw-w64-*-python3-*-any.pkg.tar.zst A new package from start to finish Please do not create pull requests for PKGBUILDs that just repackage binary releases from other projects. This is contrary to the goals of MSYS2. If the software cannot be built for some reason then try to fix the cause of that. Decide which subsystem to target ( msys or mingw ) Build the software in the target subsystem Test the functionality Create patches if necessary and repeat Prepare a recipe Build the package Install the package locally Test the installed package Modify the recipe if necessary and repeat Commit the new package to the target repository (on your own GitHub account) Send a pull request to merge the new recipe into the official repository Check CI results, reviews and comments Fix issues if necessary and repeat Offer your fixes to the software's developers (upstream) The steps above describe an intuitive process of going from the idea of creating a package to making it available to you and others using pacman . You can of course customize the process to suit you and your situation. Once you are familiar with the process, we recommend creating recipes and using makepkg straight away for all packages. It's a great way to record your build steps in a reproducible way, which is not only useful for you, but also for other people when asked for help with the builds. Which subsystem? In MSYS2 there are 2 types of packages: msys packages - these run on the emulation layer and are typically POSIX-only programs mingw packages - these run natively just like any other Windows program You should think of these two systems as separate where msys packages should generally only be build dependencies of mingw packages. You also can't link a mingw program against an msys library. This means you first need to decide which subsystem (and which repository) is the right one for your new package. The set of things that belong to the msys subsystem is pretty small: essential POSIX stuff: filesystem , msys2-runtime , ... the native toolchain: gcc , binutils , gdb , ... supporting programs that are hard to port to Windows: pacman , bash , automake , make , ... programs for bridging the gap: mintty , winpty , ... supporting programs, even though they're portable: python , man , vim , git , ... carefully chosen useful tools: mc , ssh , rsync , lftp , ... dependencies of these packages In other words, if a program is needed to build native software, but is itself hard to port, it can be made into an msys package. Anything else needs to be done as a mingw package or vetted individually. Build software In order to be able to compile a software or build a package you need to install basic packages, as the MSYS2 install does not contain build tools. The core packages groups you need to install if you wish to build from PKGBUILDs are: base-devel for any building msys2-devel for building msys packages mingw-w64-i686-toolchain for building mingw32 packages mingw-w64-x86_64-toolchain for building mingw64 packages If you don't install the required package group, building might fail with unexpected errors. Note that -- contrary to what you might expect -- base-devel doesn't contain gcc nor binutils . Test software Check that the software does what it should. Try its test suite. Patch software If the software doesn't work straight away or doesn't even build, you'll probably need to pass some arguments to the build scripts or modify (patch) its build system, its source code, its definitions files etc. Such patches will be stored as files alongside the PKGBUILD. This part is very specific to each software and may require searching the Internet, talking to the software's developers or support team, talking to us etc. The Porting wikipage may help with some common issues. While it is probably okay to make quick (monkey-)patches that fix the software for our use case (and possibly break it for every other), is it better to make proper surgical-precision patches and attempt to have them accepted by the software developer (\"upstream\"). Recipe Create a PKGBUILD describing all the steps necessary to build and package the software, including any patches or additional files. Make sure the follow the style and ideas of other recipes if applicable. A good strategy is to find some existing working recipes that use the same build system as your software does and use them as a template for your recipe. You can also take inspiration from an official Arch Linux (or unofficial AUR) recipe for your software. Build package Run the makepkg command ( makepkg or makepkg-mingw ) on your recipe. makepkg-mingw is essentially a wrapper that does a few checks, sets up the correct environments and runs makepkg twice, once for mingw32 and once for mingw64 . If you want to build just for one architecture (e.g. if you're on 32-bit Windows), you'll need to define MINGW_ARCH in the environment, with either mingw32 or mingw64 as the value, for example: MINGW_ARCH=mingw64 makepkg-mingw -sCLf ... or you could export it from ~/.profile so it's set up automatically: export MINGW_ARCH = mingw64 Note that if you want to contribute, we'd appreciate it if you test your packages on both architectures (32 and 64 bits), which is only possible on a 64-bit Windows system. If you can't do that for some reason, we can test your pull requests on a 64-bit system. Install package If the package build successfully, it's good to check its contents first before installing to see if it contains what you intended. When installing (using pacman -U pkgname-pkgver-arch.tar.zst ), pacman checks for any filesystem conflicts and then places the package contents into your MSYS2 root as it would do with any other package. You can also remove the package using pacman -R pkgname . Test package Make sure the package installed all the files which it's supposed to distribute: executables, shared and static libraries, configuration files, header files, licenses, documentation etc. Pay special attention to the configuration files and make sure they are not containing hard-coded path elements and are pointing to the right location. Typical config files: *-config files in the ${prefix}/bin directory *.pc files for pkg-config in the ${prefix}/lib/pkgconfig directory *.cmake files in the ${prefix}/lib/cmake directory Verify that the package works even if installed into a clean updated MSYS2 installation, preferably not in the default C:\\msys{32,64} location (and maybe even temporarily rename your primary MSYS2 installation root). This checks that you specified the runtime dependencies correctly and that the software doesn't try to use hard-coded paths from your build. Modify package If there are issues, fix them in your PKGBUILD and re-build or re-package as necessary. Make sure you're not using stale build products or source files from a previous build (use the -C flag for makepkg). Commit Integrate your recipe into your local clone of the msys2-packages or mingw-packages repository. In order to help us avoid accumulating useless commits in the repository, please follow these guidelines: create a new branch for your work put all your work into it, preferably in just 1 commit if you want to pull changes from our repository, use the rebasing strategy ( git pull --rebase ) to place your commits above ours, do not just merge if you need to change something in your recipe, amend your existing commit ( git commit --amend ) push your new branch onto your repository \"fork\" on your GitHub account, using git push --force-with-lease if necessary Although these guidelines (which rely heavily on rewriting history) are not suitable for public development on main branches ( master etc.), they're an excellent match for this kind the iterative work-in-progress development that happens when contributing new packages. Send PR Open and send a pull request against the master branch of the official repositories on GitHub ( links here ). Please include a short description of what you're submitting and why. In case your recipe is not final yet, add \"[do not merge]\" to the title and explain in the description. Check Our CI systems will automatically try to build your package. If it fails, try to figure out why. However, the CI systems are not perfect and unfortunately may fail even if your package is fine. The project maintainers will try to look at your PR and review it. This may take some time and sometimes happens in bursts, so don't be discouraged if you get no response for a few days, but don't be afraid to explicitly ask for help or a review on our IRC channel. Fix If there are any issues pointed out, try to fix them and update your pull request. GitHub will automatically refresh the pull request when you push to your branch, there is no need to create a new PR. After pushing, add a comment to the PR to notify the reviewers. If there are no issues with the package, it will be merged. Please note that this doesn't make the package immediately available through pacman. The binary repositories are updated in bursts. Upstream In case you had to made changes in order to be able to compile and run properly (and hence created patches), please make an effort to submit proper patches and PRs to the upstream project so that the patches can be removed from our repositories and can be of use to other Windows developers. Resources Read through our wiki, especially about pacman and the Porting section . Useful packages and tools Package Purpose mingw-w64-{i686,x86_64}-qt-creator to build/debug qmake, qbs, autotools and cmake based packages mingw-w64-{i686,x86_64}-codelite-git if you dislike qt-creator mingw-w64-{i686,x86_64}-gedit to avoid notepad and notepad++ mingw-w64-{i686,x86_64}-meld3 to compare files and directories perl-ack Faster, better replacement for grep mingw-w64-{i686,x86_64}-ag Very fast replacement for grep or perl-ack Various links bash on ArchWiki","title":"Creating Packages"},{"location":"wiki/Creating-Packages/#general-information","text":"There are 3 package repositories, msys , mingw32 , and mingw64 . msys software (from the msys repository) is software that depends on msys-2.0.dll and is very similar to Cygwin software (which is a POSIX emulation layer for Windows). Native Windows software (from this project's perspective) is software that doesn't depend on msys-2.0.dll , and links dynamically to the highly compatible msvcrt.dll . In this document, to attempt to avoid confusion, MSYS2 refers to the software distribution while msys refers to the repository, the packages in that repository and the software in those packages that link to msys-2.0.dll .","title":"General information"},{"location":"wiki/Creating-Packages/#package-recipes","text":"Packages are built from programmatic recipes to ensure builds are reproducible. A recipe is a set of files which describe how to build, package and install a given piece of software; these are often specific to MSYS2. In the simplest form it is a single file named PKGBUILD , which contains metadata for the package, a specification where the source for the given software can be found, and a few lines of code which that takes the source and builds the final software from it. For more complex cases it also contains install scripts or a number of patch files which are needed to be applied on the released version of the upstream software in order to be able to compile and work in the given environment. Typically, each recipe is in its own directory. The directory is also used when building as a working place by default.","title":"Package recipes"},{"location":"wiki/Creating-Packages/#pkgbuild","text":"Use 2 spaces for indentation: expand -t 2 PKGBUILD > PKGBUILD.new && mv PKGBUILD.new PKGBUILD A PKGBUILD is a bash script defining variables and functions that are then used by the build system to create the package. The PKGBUILD manpage and the PKGBUILD wikipage on ArchWiki are good sources to read about all the details of PKGBUILDs. The mingw PKGBUILDs are loosely based on the mingw-w64 cross-compilation packages guidelines in Arch Linux . If you don't want to read all that just yet, just read some existing PKGBUILDs; the purpose of most parts should be obvious.","title":"PKGBUILD"},{"location":"wiki/Creating-Packages/#patch-files","text":"When creating a patch file, you can use the following naming convention for its name: ###-target-Purpose.patch Where ### a sequence number, starting from 001 target , is the package name and version (separated by a hyphen) for which the patch was first created [Purpose] describes what the patch is fixing or improving","title":"Patch files"},{"location":"wiki/Creating-Packages/#building","text":"The actual build and packaging is done by running makepkg or makepkg-mingw . The former is used to build msys packages and the latter for mingw packages. To learn more, read the makepkg manpage and the makepkg wikipage on ArchWiki . When building either msys or native software, you should use the MSYS shell, not the MINGW{32,64} shells. The process happens in multiple phases: download, verify and extract - the package sources are downloaded if necessary, checked against checksums and PGP signatures if specified, and extracted into a working directory ( src by default) prepare() - using this function, the packager can specify what should happen with the sources before the actual build; apply patches and source modifications here build() - this function contains commands to run the build tool(s), e.g. ./configure and make check() - an optional step to check the build products by e.g. running the software's test suite package() - this function is provided with a temporary directory, where it should put the final contents of the package using e.g. make install tidy, archive and sign - the package contents are scanned for some issues, tidied up and packaged into the final .tar.zst with an optional signature in .tar.zst.sig The makepkg tool takes arguments allowing you to turn off some phases or some checks. The typical usage is makepkg -sCLf for a full build and makepkg -RdLf for a \"re-package\". Re-packaging is useful when the process failed in package() and you don't want to run the long build part again. makepkg-mingw takes the same arguments.","title":"Building"},{"location":"wiki/Creating-Packages/#re-building-a-package","text":"To get you started, you can try just re-building an existing package. This may also be helpful if you need to diagnose an issue and need the debugging symbols. An example of fetching the msys repository source, building and then installing a package from it is: git clone \"https://github.com/msys2/MSYS2-packages\" cd MSYS2-packages/flex makepkg -sCLf pacman -U flex-*.pkg.tar.zst An example of fetching the mingw repository source, building and then installing a package from it is: git clone \"https://github.com/msys2/MINGW-packages\" cd MINGW-packages/mingw-w64-python3 makepkg-mingw -sCLf pacman -U mingw-w64-*-python3-*-any.pkg.tar.zst","title":"Re-building a package"},{"location":"wiki/Creating-Packages/#a-new-package-from-start-to-finish","text":"Please do not create pull requests for PKGBUILDs that just repackage binary releases from other projects. This is contrary to the goals of MSYS2. If the software cannot be built for some reason then try to fix the cause of that. Decide which subsystem to target ( msys or mingw ) Build the software in the target subsystem Test the functionality Create patches if necessary and repeat Prepare a recipe Build the package Install the package locally Test the installed package Modify the recipe if necessary and repeat Commit the new package to the target repository (on your own GitHub account) Send a pull request to merge the new recipe into the official repository Check CI results, reviews and comments Fix issues if necessary and repeat Offer your fixes to the software's developers (upstream) The steps above describe an intuitive process of going from the idea of creating a package to making it available to you and others using pacman . You can of course customize the process to suit you and your situation. Once you are familiar with the process, we recommend creating recipes and using makepkg straight away for all packages. It's a great way to record your build steps in a reproducible way, which is not only useful for you, but also for other people when asked for help with the builds.","title":"A new package from start to finish"},{"location":"wiki/Creating-Packages/#which-subsystem","text":"In MSYS2 there are 2 types of packages: msys packages - these run on the emulation layer and are typically POSIX-only programs mingw packages - these run natively just like any other Windows program You should think of these two systems as separate where msys packages should generally only be build dependencies of mingw packages. You also can't link a mingw program against an msys library. This means you first need to decide which subsystem (and which repository) is the right one for your new package. The set of things that belong to the msys subsystem is pretty small: essential POSIX stuff: filesystem , msys2-runtime , ... the native toolchain: gcc , binutils , gdb , ... supporting programs that are hard to port to Windows: pacman , bash , automake , make , ... programs for bridging the gap: mintty , winpty , ... supporting programs, even though they're portable: python , man , vim , git , ... carefully chosen useful tools: mc , ssh , rsync , lftp , ... dependencies of these packages In other words, if a program is needed to build native software, but is itself hard to port, it can be made into an msys package. Anything else needs to be done as a mingw package or vetted individually.","title":"Which subsystem?"},{"location":"wiki/Creating-Packages/#build-software","text":"In order to be able to compile a software or build a package you need to install basic packages, as the MSYS2 install does not contain build tools. The core packages groups you need to install if you wish to build from PKGBUILDs are: base-devel for any building msys2-devel for building msys packages mingw-w64-i686-toolchain for building mingw32 packages mingw-w64-x86_64-toolchain for building mingw64 packages If you don't install the required package group, building might fail with unexpected errors. Note that -- contrary to what you might expect -- base-devel doesn't contain gcc nor binutils .","title":"Build software"},{"location":"wiki/Creating-Packages/#test-software","text":"Check that the software does what it should. Try its test suite.","title":"Test software"},{"location":"wiki/Creating-Packages/#patch-software","text":"If the software doesn't work straight away or doesn't even build, you'll probably need to pass some arguments to the build scripts or modify (patch) its build system, its source code, its definitions files etc. Such patches will be stored as files alongside the PKGBUILD. This part is very specific to each software and may require searching the Internet, talking to the software's developers or support team, talking to us etc. The Porting wikipage may help with some common issues. While it is probably okay to make quick (monkey-)patches that fix the software for our use case (and possibly break it for every other), is it better to make proper surgical-precision patches and attempt to have them accepted by the software developer (\"upstream\").","title":"Patch software"},{"location":"wiki/Creating-Packages/#recipe","text":"Create a PKGBUILD describing all the steps necessary to build and package the software, including any patches or additional files. Make sure the follow the style and ideas of other recipes if applicable. A good strategy is to find some existing working recipes that use the same build system as your software does and use them as a template for your recipe. You can also take inspiration from an official Arch Linux (or unofficial AUR) recipe for your software.","title":"Recipe"},{"location":"wiki/Creating-Packages/#build-package","text":"Run the makepkg command ( makepkg or makepkg-mingw ) on your recipe. makepkg-mingw is essentially a wrapper that does a few checks, sets up the correct environments and runs makepkg twice, once for mingw32 and once for mingw64 . If you want to build just for one architecture (e.g. if you're on 32-bit Windows), you'll need to define MINGW_ARCH in the environment, with either mingw32 or mingw64 as the value, for example: MINGW_ARCH=mingw64 makepkg-mingw -sCLf ... or you could export it from ~/.profile so it's set up automatically: export MINGW_ARCH = mingw64 Note that if you want to contribute, we'd appreciate it if you test your packages on both architectures (32 and 64 bits), which is only possible on a 64-bit Windows system. If you can't do that for some reason, we can test your pull requests on a 64-bit system.","title":"Build package"},{"location":"wiki/Creating-Packages/#install-package","text":"If the package build successfully, it's good to check its contents first before installing to see if it contains what you intended. When installing (using pacman -U pkgname-pkgver-arch.tar.zst ), pacman checks for any filesystem conflicts and then places the package contents into your MSYS2 root as it would do with any other package. You can also remove the package using pacman -R pkgname .","title":"Install package"},{"location":"wiki/Creating-Packages/#test-package","text":"Make sure the package installed all the files which it's supposed to distribute: executables, shared and static libraries, configuration files, header files, licenses, documentation etc. Pay special attention to the configuration files and make sure they are not containing hard-coded path elements and are pointing to the right location. Typical config files: *-config files in the ${prefix}/bin directory *.pc files for pkg-config in the ${prefix}/lib/pkgconfig directory *.cmake files in the ${prefix}/lib/cmake directory Verify that the package works even if installed into a clean updated MSYS2 installation, preferably not in the default C:\\msys{32,64} location (and maybe even temporarily rename your primary MSYS2 installation root). This checks that you specified the runtime dependencies correctly and that the software doesn't try to use hard-coded paths from your build.","title":"Test package"},{"location":"wiki/Creating-Packages/#modify-package","text":"If there are issues, fix them in your PKGBUILD and re-build or re-package as necessary. Make sure you're not using stale build products or source files from a previous build (use the -C flag for makepkg).","title":"Modify package"},{"location":"wiki/Creating-Packages/#commit","text":"Integrate your recipe into your local clone of the msys2-packages or mingw-packages repository. In order to help us avoid accumulating useless commits in the repository, please follow these guidelines: create a new branch for your work put all your work into it, preferably in just 1 commit if you want to pull changes from our repository, use the rebasing strategy ( git pull --rebase ) to place your commits above ours, do not just merge if you need to change something in your recipe, amend your existing commit ( git commit --amend ) push your new branch onto your repository \"fork\" on your GitHub account, using git push --force-with-lease if necessary Although these guidelines (which rely heavily on rewriting history) are not suitable for public development on main branches ( master etc.), they're an excellent match for this kind the iterative work-in-progress development that happens when contributing new packages.","title":"Commit"},{"location":"wiki/Creating-Packages/#send-pr","text":"Open and send a pull request against the master branch of the official repositories on GitHub ( links here ). Please include a short description of what you're submitting and why. In case your recipe is not final yet, add \"[do not merge]\" to the title and explain in the description.","title":"Send PR"},{"location":"wiki/Creating-Packages/#check","text":"Our CI systems will automatically try to build your package. If it fails, try to figure out why. However, the CI systems are not perfect and unfortunately may fail even if your package is fine. The project maintainers will try to look at your PR and review it. This may take some time and sometimes happens in bursts, so don't be discouraged if you get no response for a few days, but don't be afraid to explicitly ask for help or a review on our IRC channel.","title":"Check"},{"location":"wiki/Creating-Packages/#fix","text":"If there are any issues pointed out, try to fix them and update your pull request. GitHub will automatically refresh the pull request when you push to your branch, there is no need to create a new PR. After pushing, add a comment to the PR to notify the reviewers. If there are no issues with the package, it will be merged. Please note that this doesn't make the package immediately available through pacman. The binary repositories are updated in bursts.","title":"Fix"},{"location":"wiki/Creating-Packages/#upstream","text":"In case you had to made changes in order to be able to compile and run properly (and hence created patches), please make an effort to submit proper patches and PRs to the upstream project so that the patches can be removed from our repositories and can be of use to other Windows developers.","title":"Upstream"},{"location":"wiki/Creating-Packages/#resources","text":"Read through our wiki, especially about pacman and the Porting section .","title":"Resources"},{"location":"wiki/Creating-Packages/#useful-packages-and-tools","text":"Package Purpose mingw-w64-{i686,x86_64}-qt-creator to build/debug qmake, qbs, autotools and cmake based packages mingw-w64-{i686,x86_64}-codelite-git if you dislike qt-creator mingw-w64-{i686,x86_64}-gedit to avoid notepad and notepad++ mingw-w64-{i686,x86_64}-meld3 to compare files and directories perl-ack Faster, better replacement for grep mingw-w64-{i686,x86_64}-ag Very fast replacement for grep or perl-ack","title":"Useful packages and tools"},{"location":"wiki/Creating-Packages/#various-links","text":"bash on ArchWiki","title":"Various links"},{"location":"wiki/Devtopics/","text":"Here are some topics and milestones that deserve more discussion or work. This page should serve as an overview of our long-term issues and goals and be a place to write down the decisions and open questions so that they don't get buried in IRC logs or mailing list archives. Each goal should be described in appropriate detail and should be broken up into smaller tasks for interested members to tackle the goal step by step. Unify public relations, solidify hosting People are sometimes (often?) confused about where to get information about the project. It would be great if all the user-facing parts were on msys2.org and all the developer-facing parts on GitHub. Back-ends can be wherever (mailing lists and big file storage would be examples of things that we can't do with GitHub). @alexpux doesn't agree, but @elieux believes one issue tracker for the whole project is better than separate ones. Git for Windows sets a particularly good example. We currently have: GitHub org for our main repositories (it had the wiki in the past) a secondary GitHub org for contributions upstream and as a working place other GitHub repos for source and issue tracking, msys2-pacman SourceForge project for mailing lists and as a mirror (it had forums and the wiki in the past) https://msys2.org (also msys2.com and msys2.net), our own domains (owned by @elieux), with installation and donation instructions and the documentation with source on GitHub an online repo browser , hosted by @lazka http://repo.msys2.org as the source for mirrors and a canonical location for installers, hosted by @elieux twitter account , run by @lazka What to do: migrate tickets from SF to GH; close them on SF afterwards migrate forums and discussion from SF to GH move active MSYS2-related repositories on GH to the msys2 org, including issues find more (fast and reliable) mirrors try moving the mailing list including archives from SF, see mbox export ; can we use Sourceware? can we have our own (some say that mailman on our own server would be spam-filtered badly)? notify list members of the change (possibly set up a redirect for some time) change links in packages (\"submit bug\" URLs) and elsewhere Off-load package building and uploading For a long time, @alexpux was responsible for building all packages. Ray, Renato, Qian, and other people had tried to use various CI platforms, with varying results. Since 2020, @lazka and @eine have set up a CI to automatically build most packages in https://github.com/msys2/msys2-autobuild in cooperation with an API on https://packages.msys2.org/ . Now @elieux is only responsible for uploading and signing them. Approving pull requests for packages is done by a number of people. What to do: write down packaging rules (rules inherited from Arch Linux, rules about pkgbase , pkgname , description , FHS, 32+64 bits, ...) prepare automated checks to prevent mistakes (an idea: compare package file list between latest and new version of the package) automate signing and uploading of packages? also work towards reproducible builds ( https://reproducible-builds.org/ ) Official release MSYS2 is quite known but it's not obvious e.g. how stable and reliable it's supposed to be. People are sometimes confusing it (in their minds, or in their words, or both) with MSys, much like MinGW-w64 is confused with MinGW.org. The naming clash of MSYS2 the distribution vs. msys2 the emulation layer is also unfortunate (again reminiscent of the MinGW-w64 projects vs. its distributions). What to do: decide if there's a need for a different name for the whole thing ; if yes, decide upon one split release Qt runtime from debug Qt runtime and Qt developer files (those debug and dev files are really huge) make core updates fool-proof maybe approve and polish one graphical front-end to pacman create and/or polish packages for most popular open-source software (browsers, video players, email clients, office suites, IDEs, web servers) and maybe some additional useful software (like password managers, games, image editors) Merge with Cygwin The MSYS2 runtime is forked from Cygwin and the code bases are irregularly (but often) synchronized. There has been some talk about modifying Cygwin to make it pluggable so that the MSYS2 runtime can be reduced to a plugin DLL that will make all the desired behavior changes. There has been a lot of requests for additional POSIX-only software in MSYS2 (X, various daemons...) and the response was always \"MSYS2 is not for you; use Cygwin\". It would be nice if people could just install one POSIX emulation layer and have everything available from there. What to do: write down every difference between Cygwin and MSYS2 runtimes (see the patches ) offer appropriate patches to Cygwin as configurable behavior (e.g. CYGWIN=winsymlinks:copy) design an interface prototype for unacceptable features; figure out if the idea is sound design and implement the plug-in interface in cooperation with Cygwin re-implement MSYS2 runtime as a Cygwin plugin figure out if we can use Cygwin package repositories or if MSYS2 repositories can be used from Cygwin Links: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/2F9017D3-8357-48C2-B887-A32FDF4E2141@gmail.com/ http://sourceware.org/ml/cygwin/2014-12/msg00084.html https://github.com/Alexpux/MSYS2-packages/issues/83 Connect with upstreams Where possible, we shouldn't maintain a bunch of patches, but rather polish them and have them accepted by upstreams. Another change to consider is to start building only release versions of the core packages. Although MSYS2 is a rolling release distro, there seems to be little need to use less tested, potentially more buggy code directly from git. If there's a really important, not yet realeased patch, we apply it in the PKGBUILD until the next release. Currently the mingw-w64 toolchains are the most prominent examples. switch to release versions of upstream code improve technical quality of packages (make sure they follow all the packaging rules, tests are succeeding) send ideas and patches upstream, be prepared to compromise Connect with downstreams Altough we are probably not so big among end-users yet, a lot of cross-platform developers know about MSYS2 and support it and even some big projects use it for their official builds. Some applications and environments use MSYS2 internally. We should get in touch with them and help them (it is, after all, one of the core goals of the project). Links: https://vcpkg.readthedocs.io/en/latest/maintainers/vcpkg_acquire_msys/ https://chocolatey.org/packages/msys2/ https://github.com/msys2/setup-msys2 https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md ( https://github.com/actions/virtual-environments/pull/632 + https://github.com/actions/virtual-environments/pull/630 ) https://www.appveyor.com/docs/windows-images-software/#mingw-msys-cygwin https://docs.travis-ci.com/user/reference/windows/#how-do-i-use-msys2 https://circleci.com/docs/2.0/hello-world-windows/ https://github.com/git-for-windows/git/issues/284 https://github.com/Alexpux/Cygwin/pull/8 https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/windows https://wiki.qt.io/MSYS2 https://www.gtk.org/download/windows.php#MSYS2 https://cran.r-project.org/bin/windows/Rtools/ https://wiki.inkscape.org/wiki/index.php?title=Compiling_Inkscape_on_Windows_with_MSYS2 https://wiki.gnome.org/Initiatives/Windows https://github.com/xmrig/xmrig/wiki/Windows-Build https://github.com/LuminanceHDR/LuminanceHDR/tree/master/build_files/platforms/msys2 https://sigrok.org/gitweb/?p=sigrok-util.git;a=blob;f=cross-compile/msys2/README https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/ Get more people The MSYS2 team is pretty small and we could use more people. Some contributors become pretty active and motivated from time to time, but often they burn out after a while. Since there are so few of core people, the occasional interested users, contributors and issue reporters are often greeted by silence and turned off. What to do to get them: respond to them on IRC, Gitter, ML, handle their bug reports and contributions on GitHub in a timely fashion good documentation helps with frequent inquiries, automated checks help with code reviews get money and pay people? other ideas? Links: https://www.msys2.org/wiki/Contributing-to-MSYS2/ Fix pacman errors wrt. conflicts in bin/foo vs bin/foo.exe The runtime emulates extension-less executables by also looking for .exe on various FS calls. (There are more of these hacks, for example for symlink emulation.) This is causing pacman to complain when two packages independently provide both foo and foo.exe , or even worse dir/ and dir.exe . People have to either disregard these conflicts with --force or (re-)install packages in a specific order. A possible solution to these conflicts would be to disable the .exe interpolation, but then something would break, either users wouldn't be able to either run MSYS2 executables directly from Windows, or couldn't use the short extension-less names of commands in MSYS2. Therefore there also has to be a change that will mitigate that. We can for example design some passes for makepkg : make sure every .exe going into {,/usr}/{bin,lib,libexec}/ has its extension stripped make sure only .{exe,dll} go into /mingw{32,64}/bin/ build a good .exe wrapper for every executable in MSYS-land build a good shell wrapper for every executable in MINGW-land This way, we can even make all non-binaries like shell scripts directly executable from Windows. What to help with: think/discuss if this is a good idea Provide more mingw-w64 versions of common CLI tools It would be nice to allow people to have as complete as possible GNU-like environment without having to fall back to msys2 bash and the likes. The roadblock in this is that by putting every possible tool into /mingw{32,64}/bin will inevitably screw up native (i.e. non-cross) builds. Ideas for solutions: for every tool that's known to cause problems inside of MSYS2, include shell scripts in /mingw{32,64}/bin/ that take priority over the .exe s. separate the essential build tools from everything else; (by using symlinks, aliases, or just using the package manager) we could have gcc, binutils and friends in /mingw{32,64}/bin/ and everything else for instance in /mingw{32,64}/morebin/ so that a MSYS2/MINGW shell only uses the bin , but people can opt in for using morebin outside of MSYS2 What to help with: design, test, agree on, and implement a way to prevent problems when building port all the tools! Links: Pull requests from @pfmoore GnuWin UnxUtils GNU on Windows mksh/Win32 busybox-w32 and MinGit and mingw-w64-busybox Midipix Maybe?","title":"TODO LIST"},{"location":"wiki/Devtopics/#unify-public-relations-solidify-hosting","text":"People are sometimes (often?) confused about where to get information about the project. It would be great if all the user-facing parts were on msys2.org and all the developer-facing parts on GitHub. Back-ends can be wherever (mailing lists and big file storage would be examples of things that we can't do with GitHub). @alexpux doesn't agree, but @elieux believes one issue tracker for the whole project is better than separate ones. Git for Windows sets a particularly good example. We currently have: GitHub org for our main repositories (it had the wiki in the past) a secondary GitHub org for contributions upstream and as a working place other GitHub repos for source and issue tracking, msys2-pacman SourceForge project for mailing lists and as a mirror (it had forums and the wiki in the past) https://msys2.org (also msys2.com and msys2.net), our own domains (owned by @elieux), with installation and donation instructions and the documentation with source on GitHub an online repo browser , hosted by @lazka http://repo.msys2.org as the source for mirrors and a canonical location for installers, hosted by @elieux twitter account , run by @lazka What to do: migrate tickets from SF to GH; close them on SF afterwards migrate forums and discussion from SF to GH move active MSYS2-related repositories on GH to the msys2 org, including issues find more (fast and reliable) mirrors try moving the mailing list including archives from SF, see mbox export ; can we use Sourceware? can we have our own (some say that mailman on our own server would be spam-filtered badly)? notify list members of the change (possibly set up a redirect for some time) change links in packages (\"submit bug\" URLs) and elsewhere","title":"Unify public relations, solidify hosting"},{"location":"wiki/Devtopics/#off-load-package-building-and-uploading","text":"For a long time, @alexpux was responsible for building all packages. Ray, Renato, Qian, and other people had tried to use various CI platforms, with varying results. Since 2020, @lazka and @eine have set up a CI to automatically build most packages in https://github.com/msys2/msys2-autobuild in cooperation with an API on https://packages.msys2.org/ . Now @elieux is only responsible for uploading and signing them. Approving pull requests for packages is done by a number of people. What to do: write down packaging rules (rules inherited from Arch Linux, rules about pkgbase , pkgname , description , FHS, 32+64 bits, ...) prepare automated checks to prevent mistakes (an idea: compare package file list between latest and new version of the package) automate signing and uploading of packages? also work towards reproducible builds ( https://reproducible-builds.org/ )","title":"Off-load package building and uploading"},{"location":"wiki/Devtopics/#official-release","text":"MSYS2 is quite known but it's not obvious e.g. how stable and reliable it's supposed to be. People are sometimes confusing it (in their minds, or in their words, or both) with MSys, much like MinGW-w64 is confused with MinGW.org. The naming clash of MSYS2 the distribution vs. msys2 the emulation layer is also unfortunate (again reminiscent of the MinGW-w64 projects vs. its distributions). What to do: decide if there's a need for a different name for the whole thing ; if yes, decide upon one split release Qt runtime from debug Qt runtime and Qt developer files (those debug and dev files are really huge) make core updates fool-proof maybe approve and polish one graphical front-end to pacman create and/or polish packages for most popular open-source software (browsers, video players, email clients, office suites, IDEs, web servers) and maybe some additional useful software (like password managers, games, image editors)","title":"Official release"},{"location":"wiki/Devtopics/#merge-with-cygwin","text":"The MSYS2 runtime is forked from Cygwin and the code bases are irregularly (but often) synchronized. There has been some talk about modifying Cygwin to make it pluggable so that the MSYS2 runtime can be reduced to a plugin DLL that will make all the desired behavior changes. There has been a lot of requests for additional POSIX-only software in MSYS2 (X, various daemons...) and the response was always \"MSYS2 is not for you; use Cygwin\". It would be nice if people could just install one POSIX emulation layer and have everything available from there. What to do: write down every difference between Cygwin and MSYS2 runtimes (see the patches ) offer appropriate patches to Cygwin as configurable behavior (e.g. CYGWIN=winsymlinks:copy) design an interface prototype for unacceptable features; figure out if the idea is sound design and implement the plug-in interface in cooperation with Cygwin re-implement MSYS2 runtime as a Cygwin plugin figure out if we can use Cygwin package repositories or if MSYS2 repositories can be used from Cygwin Links: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/2F9017D3-8357-48C2-B887-A32FDF4E2141@gmail.com/ http://sourceware.org/ml/cygwin/2014-12/msg00084.html https://github.com/Alexpux/MSYS2-packages/issues/83","title":"Merge with Cygwin"},{"location":"wiki/Devtopics/#connect-with-upstreams","text":"Where possible, we shouldn't maintain a bunch of patches, but rather polish them and have them accepted by upstreams. Another change to consider is to start building only release versions of the core packages. Although MSYS2 is a rolling release distro, there seems to be little need to use less tested, potentially more buggy code directly from git. If there's a really important, not yet realeased patch, we apply it in the PKGBUILD until the next release. Currently the mingw-w64 toolchains are the most prominent examples. switch to release versions of upstream code improve technical quality of packages (make sure they follow all the packaging rules, tests are succeeding) send ideas and patches upstream, be prepared to compromise","title":"Connect with upstreams"},{"location":"wiki/Devtopics/#connect-with-downstreams","text":"Altough we are probably not so big among end-users yet, a lot of cross-platform developers know about MSYS2 and support it and even some big projects use it for their official builds. Some applications and environments use MSYS2 internally. We should get in touch with them and help them (it is, after all, one of the core goals of the project). Links: https://vcpkg.readthedocs.io/en/latest/maintainers/vcpkg_acquire_msys/ https://chocolatey.org/packages/msys2/ https://github.com/msys2/setup-msys2 https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md ( https://github.com/actions/virtual-environments/pull/632 + https://github.com/actions/virtual-environments/pull/630 ) https://www.appveyor.com/docs/windows-images-software/#mingw-msys-cygwin https://docs.travis-ci.com/user/reference/windows/#how-do-i-use-msys2 https://circleci.com/docs/2.0/hello-world-windows/ https://github.com/git-for-windows/git/issues/284 https://github.com/Alexpux/Cygwin/pull/8 https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/windows https://wiki.qt.io/MSYS2 https://www.gtk.org/download/windows.php#MSYS2 https://cran.r-project.org/bin/windows/Rtools/ https://wiki.inkscape.org/wiki/index.php?title=Compiling_Inkscape_on_Windows_with_MSYS2 https://wiki.gnome.org/Initiatives/Windows https://github.com/xmrig/xmrig/wiki/Windows-Build https://github.com/LuminanceHDR/LuminanceHDR/tree/master/build_files/platforms/msys2 https://sigrok.org/gitweb/?p=sigrok-util.git;a=blob;f=cross-compile/msys2/README https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/","title":"Connect with downstreams"},{"location":"wiki/Devtopics/#get-more-people","text":"The MSYS2 team is pretty small and we could use more people. Some contributors become pretty active and motivated from time to time, but often they burn out after a while. Since there are so few of core people, the occasional interested users, contributors and issue reporters are often greeted by silence and turned off. What to do to get them: respond to them on IRC, Gitter, ML, handle their bug reports and contributions on GitHub in a timely fashion good documentation helps with frequent inquiries, automated checks help with code reviews get money and pay people? other ideas? Links: https://www.msys2.org/wiki/Contributing-to-MSYS2/","title":"Get more people"},{"location":"wiki/Devtopics/#fix-pacman-errors-wrt-conflicts-in-binfoo-vs-binfooexe","text":"The runtime emulates extension-less executables by also looking for .exe on various FS calls. (There are more of these hacks, for example for symlink emulation.) This is causing pacman to complain when two packages independently provide both foo and foo.exe , or even worse dir/ and dir.exe . People have to either disregard these conflicts with --force or (re-)install packages in a specific order. A possible solution to these conflicts would be to disable the .exe interpolation, but then something would break, either users wouldn't be able to either run MSYS2 executables directly from Windows, or couldn't use the short extension-less names of commands in MSYS2. Therefore there also has to be a change that will mitigate that. We can for example design some passes for makepkg : make sure every .exe going into {,/usr}/{bin,lib,libexec}/ has its extension stripped make sure only .{exe,dll} go into /mingw{32,64}/bin/ build a good .exe wrapper for every executable in MSYS-land build a good shell wrapper for every executable in MINGW-land This way, we can even make all non-binaries like shell scripts directly executable from Windows. What to help with: think/discuss if this is a good idea","title":"Fix pacman errors wrt. conflicts in bin/foo vs bin/foo.exe"},{"location":"wiki/Devtopics/#provide-more-mingw-w64-versions-of-common-cli-tools","text":"It would be nice to allow people to have as complete as possible GNU-like environment without having to fall back to msys2 bash and the likes. The roadblock in this is that by putting every possible tool into /mingw{32,64}/bin will inevitably screw up native (i.e. non-cross) builds. Ideas for solutions: for every tool that's known to cause problems inside of MSYS2, include shell scripts in /mingw{32,64}/bin/ that take priority over the .exe s. separate the essential build tools from everything else; (by using symlinks, aliases, or just using the package manager) we could have gcc, binutils and friends in /mingw{32,64}/bin/ and everything else for instance in /mingw{32,64}/morebin/ so that a MSYS2/MINGW shell only uses the bin , but people can opt in for using morebin outside of MSYS2 What to help with: design, test, agree on, and implement a way to prevent problems when building port all the tools! Links: Pull requests from @pfmoore GnuWin UnxUtils GNU on Windows mksh/Win32 busybox-w32 and MinGit and mingw-w64-busybox","title":"Provide more mingw-w64 versions of common CLI tools"},{"location":"wiki/Devtopics/#midipix","text":"Maybe?","title":"Midipix"},{"location":"wiki/Distributing/","text":"[ This page is a stub. Help us by sending your experience and ideas for improvements. ] Possibly useful sources of information Styrene from Andrew Chadwick the build scripts for Git for Windows , especially make-file-list.sh a deploy.sh script from @rubenvb a Makefile rule from @matlo a newer Makefile rule from @matlo the pactree command a copy_dependencies.py script for librepilot from @filnet, discussion the rtools-installer project the build script for quodlibet","title":"Distributing"},{"location":"wiki/Distributing/#possibly-useful-sources-of-information","text":"Styrene from Andrew Chadwick the build scripts for Git for Windows , especially make-file-list.sh a deploy.sh script from @rubenvb a Makefile rule from @matlo a newer Makefile rule from @matlo the pactree command a copy_dependencies.py script for librepilot from @filnet, discussion the rtools-installer project the build script for quodlibet","title":"Possibly useful sources of information"},{"location":"wiki/FAQ/","text":"To read about breaking changes that used to be listed on this page, go to News . What to do when Pacman is telling me there are conflicts in the file system? This indicates that Pacman isn't sure it is safe to overwrite some files. This sometimes happens during regular package updates, but could also happen if you installed some software manually ( make install , npm install npm -g etc.). To continue with the operation, pass --overwrite <conflicting_file_path> to the Pacman command line. For other options, see the Arch Linux FAQ entry about Pacman file conflicts .","title":"FAQ"},{"location":"wiki/FAQ/#what-to-do-when-pacman-is-telling-me-there-are-conflicts-in-the-file-system","text":"This indicates that Pacman isn't sure it is safe to overwrite some files. This sometimes happens during regular package updates, but could also happen if you installed some software manually ( make install , npm install npm -g etc.). To continue with the operation, pass --overwrite <conflicting_file_path> to the Pacman command line. For other options, see the Arch Linux FAQ entry about Pacman file conflicts .","title":"What to do when Pacman is telling me there are conflicts in the file system?"},{"location":"wiki/GDB-qtcreator/","text":"This page is extremely work-in-progress. Eventually it will cover setting up Qt Creator so you can \"Start and Debug External Application ...\" (you need to build it from source to get access to the latest patch that makes this workable), rebuilding and reinstalling the involved packages in debug, !strip mode and debugging them. The also being able to see Python callstacks and pretty printing of GDB internals in-case you are debugging those sorts of things. For now, this is all I have: .. To see Python Callstacks and vars when debugging something that intermixes Python and C/C++ (e.g. pygtk) .. add to .gdbinit or QtCreator Tools->Options->Debugger->GDB->Additional Startup Commands, enter python sys.path.append('C:/msys64/mingw64/share/gdb/python3') import python-gdb reload(python-gdb) end","title":"Qt Creator"},{"location":"wiki/History/","text":"MSYS2 MSYS2 is an independent rewrite of MSYS, based on modern Cygwin and MinGW-w64 with the aim of better interoperability with native Windows software. The name is a contraction of Minimal SYStem 2, and aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains. We wanted a package management system to provide easy installation of packages, and ported Pacman (known from Arch Linux). This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system which is used to make these packages. Cygwin Cygwin is a POSIX platform atop of Windows (the Win32 subsystem), running in user-mode. It requires a POSIX compatibility layer at runtime. It doesn't emulate Linux, it's not the same thing as WSL. It is our hope that MSYS2 be viewed as a complementary off-shot of Cygwin (even hopefully by the Cygwin developers!), and we still hold out hopes that MSYS2 can someday operate as a special mode for Cygwin (via a DLL plugin mechanism). MinGW-w64 MinGW is an abbreviation of Minimalist GNU for Windows . The idea of MinGW is to provide a development platform for building cross-platform applications on Windows. The important pieces are: a set of FOSS Windows specific header files and import libraries which enable the use of the Windows API, a supplementary library and a runtime that fill in some gaps. ... but the term generally encompasses the cross-platform GNU development tools: GNU Compiler Collection (GCC), GNU Binutils (assembler, linker, archive manager), GNU Debugger (GDB), and miscellaneous utilities. There are at least two projects implementing this idea: the original MinGW project, sometimes referred to as mingw.org and the MinGW-w64 project. The MinGW-w64 project itself doesn't aim to be a software distribution. There are multiple builds of mingw-w64 toolchains and multiple software distributions built using MinGW-w64. MSYS and MinGW MinGW is a software distribution and development platform. It is accompanied by MSYS, an old Cygwin fork. The MSYS2 and MinGW-w64 projects are not associated with MSYS and MinGW, other than by the name and common goals. MSYS2 is ideologically a successor to MSYS and MinGW. MSYS -- although definitely useful -- is really old and getting in the way of developers. MSYS2 was created to replace the original MSYS while avoiding its problems.","title":"MSYS2 History"},{"location":"wiki/History/#msys2","text":"MSYS2 is an independent rewrite of MSYS, based on modern Cygwin and MinGW-w64 with the aim of better interoperability with native Windows software. The name is a contraction of Minimal SYStem 2, and aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains. We wanted a package management system to provide easy installation of packages, and ported Pacman (known from Arch Linux). This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system which is used to make these packages.","title":"MSYS2"},{"location":"wiki/History/#cygwin","text":"Cygwin is a POSIX platform atop of Windows (the Win32 subsystem), running in user-mode. It requires a POSIX compatibility layer at runtime. It doesn't emulate Linux, it's not the same thing as WSL. It is our hope that MSYS2 be viewed as a complementary off-shot of Cygwin (even hopefully by the Cygwin developers!), and we still hold out hopes that MSYS2 can someday operate as a special mode for Cygwin (via a DLL plugin mechanism).","title":"Cygwin"},{"location":"wiki/History/#mingw-w64","text":"MinGW is an abbreviation of Minimalist GNU for Windows . The idea of MinGW is to provide a development platform for building cross-platform applications on Windows. The important pieces are: a set of FOSS Windows specific header files and import libraries which enable the use of the Windows API, a supplementary library and a runtime that fill in some gaps. ... but the term generally encompasses the cross-platform GNU development tools: GNU Compiler Collection (GCC), GNU Binutils (assembler, linker, archive manager), GNU Debugger (GDB), and miscellaneous utilities. There are at least two projects implementing this idea: the original MinGW project, sometimes referred to as mingw.org and the MinGW-w64 project. The MinGW-w64 project itself doesn't aim to be a software distribution. There are multiple builds of mingw-w64 toolchains and multiple software distributions built using MinGW-w64.","title":"MinGW-w64"},{"location":"wiki/History/#msys-and-mingw","text":"MinGW is a software distribution and development platform. It is accompanied by MSYS, an old Cygwin fork. The MSYS2 and MinGW-w64 projects are not associated with MSYS and MinGW, other than by the name and common goals. MSYS2 is ideologically a successor to MSYS and MinGW. MSYS -- although definitely useful -- is really old and getting in the way of developers. MSYS2 was created to replace the original MSYS while avoiding its problems.","title":"MSYS and MinGW"},{"location":"wiki/Home/","text":"Welcome to the MSYS2 wiki Introduction - overview and important information Installing and upgrading - required reading for all users Using packages - how to find and install packages History - about the project's inception and origins Re-installing from scratch - in case of unrecoverable problems Contributing - how to help the project Creating packages - how packages are built and how to make new ones MSYS2 vs. Cygwin - differences and similarities MSYS2 on Wine - how to install and use MSYS2 under Wine [sadly broken with current version of MSYS2 and no-one is actively working on a fix as far as we know] Porting for MSYS2 or MinGW-w64 - useful resources and common issues Package list - list of packages we provide Launchers - various ways to launch MSYS2 shells Distributing software without pacman - how to bundle your software built using MSYS2, including all required dependencies, to non-MSYS2-users FAQ About terminals, consoles and shells Setting up SSHd on MSYS2 Sudo on MSYS2 Developer discussion Signing packages (draft) Tips for investigating package issues using GDB on Qt Creator (draft) More documentation: If you have any problems with the POSIX side of MSYS2 (e.g. ssh, home directories, user accounts, native symlinks, signal handling, ...), try to consult the Cygwin documentation first, as a lot of what's written there applies to MSYS2 as well. There is also an excellent introduction from Matthieu Vachon describing MSYS2, the shells, pacman and other stuff in a less technical, more practical way. Some pages on the Git for Windows wiki are relevant to MSYS2 as well. There are various communication channels set up, including the #msys2 IRC channel on OFTC and the mailing list at msys2-users@lists.sourceforge.net . Project members: Alexey (Project Leader) Ray Donnelly Martell Malone David Macek With thanks to: The MinGW-w64 Project The Cygwin Project The Qt-Project ... and all of the other Open Source software projects we build, package and distribute","title":"Welcome to the MSYS2 wiki"},{"location":"wiki/How-does-MSYS2-differ-from-Cygwin/","text":"Goals Cygwin and MSYS2 -- as projects -- have significantly different goals. Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development. MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin. MSYS2 provides a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them. The shell and core tools exist mainly to allow porting Unix programs to run natively on Windows (i.e. without requiring a POSIX emulation layer). MSYS2 doesn't try to duplicate Cygwin's efforts more than necessary, so the number of provided POSIX-emulated software is very small. Packages MSYS2 uses Pacman (known from Arch Linux) to manage its packages and comes with three different package repositories: msys2 : Containing MSYS2-dependent software mingw64 : Containing 64-bit native Windows software (compiled with mingw-w64 x86_64 toolchain) mingw32 : Containing 32-bit native Windows software (compiled with mingw-w64 i686 toolchain) Cygwin comes only with Cygwin-dependent software. It uses its own package management system, commonly called setup.exe. Runtime Cygwin provides a runtime library called cygwin1.dll that provides the POSIX compatibility layer where necessary. The MSYS2 variant of this library is called msys-2.0.dll and includes the following changes to support using native Windows programs: Automatic path mangling of command line arguments and environment variables to Windows form on the fly. (This can be selectively turned off .) Ability to change the reported OS using an environment variable ( MSYSTEM , with values of MSYS2 , MINGW32 , and MINGW64 ). This allows mingw-w64 software to be built in native build mode (as opposed to cross-compilation mode). Conversion of output of native Windown applications from Windows line endings to POSIX line endings by removing trailing '\\r' characters, so that e.g. bb=$(gcc --print-search-dirs) works as expected. Replacement of symlinks with copying, so that Windows programs don't trip up on these files. MSYS2 also supports creating native NTFS symlinks, but these are limited in other ways. Removal of the /cygdrive prefix for automounts. This is to retain compatibility with MSYS-enabled software that makes assumptions about /c/ being equivalent to C:/ , and it saves a bit of typing. Switch to noacl on default mounts. This prevents any permission mangling from MSYS2. MSYS2 releases might be ahead of or behind Cygwin releases. Other notable differences: System root is /usr , not / . Removal of system integration stuff, such as cyglsa , cygserver , cygstart ... Dynamic libraries are prefixed msys instead of cyg (most other platforms, including mingw-w64, use lib ). Addition of the \"-W\" option to the pwd command in shells for compatibility with the old MSYS. Various changes in utilities to help retain compatibility and interoperability. An example is Perl reporting msys as $^O , or Sed recognizing CRLF as a line ending.","title":"How does MSYS2 differ from Cygwin?"},{"location":"wiki/How-does-MSYS2-differ-from-Cygwin/#goals","text":"Cygwin and MSYS2 -- as projects -- have significantly different goals. Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development. MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin. MSYS2 provides a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them. The shell and core tools exist mainly to allow porting Unix programs to run natively on Windows (i.e. without requiring a POSIX emulation layer). MSYS2 doesn't try to duplicate Cygwin's efforts more than necessary, so the number of provided POSIX-emulated software is very small.","title":"Goals"},{"location":"wiki/How-does-MSYS2-differ-from-Cygwin/#packages","text":"MSYS2 uses Pacman (known from Arch Linux) to manage its packages and comes with three different package repositories: msys2 : Containing MSYS2-dependent software mingw64 : Containing 64-bit native Windows software (compiled with mingw-w64 x86_64 toolchain) mingw32 : Containing 32-bit native Windows software (compiled with mingw-w64 i686 toolchain) Cygwin comes only with Cygwin-dependent software. It uses its own package management system, commonly called setup.exe.","title":"Packages"},{"location":"wiki/How-does-MSYS2-differ-from-Cygwin/#runtime","text":"Cygwin provides a runtime library called cygwin1.dll that provides the POSIX compatibility layer where necessary. The MSYS2 variant of this library is called msys-2.0.dll and includes the following changes to support using native Windows programs: Automatic path mangling of command line arguments and environment variables to Windows form on the fly. (This can be selectively turned off .) Ability to change the reported OS using an environment variable ( MSYSTEM , with values of MSYS2 , MINGW32 , and MINGW64 ). This allows mingw-w64 software to be built in native build mode (as opposed to cross-compilation mode). Conversion of output of native Windown applications from Windows line endings to POSIX line endings by removing trailing '\\r' characters, so that e.g. bb=$(gcc --print-search-dirs) works as expected. Replacement of symlinks with copying, so that Windows programs don't trip up on these files. MSYS2 also supports creating native NTFS symlinks, but these are limited in other ways. Removal of the /cygdrive prefix for automounts. This is to retain compatibility with MSYS-enabled software that makes assumptions about /c/ being equivalent to C:/ , and it saves a bit of typing. Switch to noacl on default mounts. This prevents any permission mangling from MSYS2. MSYS2 releases might be ahead of or behind Cygwin releases. Other notable differences: System root is /usr , not / . Removal of system integration stuff, such as cyglsa , cygserver , cygstart ... Dynamic libraries are prefixed msys instead of cyg (most other platforms, including mingw-w64, use lib ). Addition of the \"-W\" option to the pwd command in shells for compatibility with the old MSYS. Various changes in utilities to help retain compatibility and interoperability. An example is Perl reporting msys as $^O , or Sed recognizing CRLF as a line ending.","title":"Runtime"},{"location":"wiki/JIT-Debugging/","text":"MSYS2 processes To get just-in-time debugging of MSYS2 processes, use the error_start MSYS environment variable setting: export MSYS = \"error_start: $( cygpath -w /usr/bin/gdb ) \" ./crashy.exe Native Windows processes MINGW gdb can be used as a Windows JIT debugger . This is documented here under signal-event . As Administrator: regtool add -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug' regtool set -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger' \\\" $( cygpath -w /mingw64/bin/gdb.exe ) '\" -ex \"attach %ld\" -ex \"signal-event %ld\" -ex \"continue\"' regtool set -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Auto' 1 regtool add -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug' regtool set -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger' \\\" $( cygpath -w /mingw32/bin/gdb.exe ) '\" -ex \"attach %ld\" -ex \"signal-event %ld\" -ex \"continue\"' regtool set -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Auto' 1 Native Windows processes started from MSYS2 When a native process which was started (possibly indirectly) from an MSYS2 process (such as bash ) crashes, it does not invoke the registered debugger (or Windows Error Reporting), unless the SetErrorMode SEM_NOGPFAULTERRORBOX flag was cleared in the meantime ( SetErrorMode flags are inherited from a parent process by default). As of msys2-runtime 3.2.0-2 , it is possible to tell MSYS2 to create processes without inheriting its error mode flags by setting an MSYS environment variable setting: export MSYS = winjitdebug exec bash ./crashy.exe (note that the option needs to be set in the parent process, so bash needs to be restarted, assuming you are starting processes from bash ).","title":"Just-in-time Debugging"},{"location":"wiki/JIT-Debugging/#msys2-processes","text":"To get just-in-time debugging of MSYS2 processes, use the error_start MSYS environment variable setting: export MSYS = \"error_start: $( cygpath -w /usr/bin/gdb ) \" ./crashy.exe","title":"MSYS2 processes"},{"location":"wiki/JIT-Debugging/#native-windows-processes","text":"MINGW gdb can be used as a Windows JIT debugger . This is documented here under signal-event . As Administrator: regtool add -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug' regtool set -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger' \\\" $( cygpath -w /mingw64/bin/gdb.exe ) '\" -ex \"attach %ld\" -ex \"signal-event %ld\" -ex \"continue\"' regtool set -w '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Auto' 1 regtool add -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug' regtool set -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Debugger' \\\" $( cygpath -w /mingw32/bin/gdb.exe ) '\" -ex \"attach %ld\" -ex \"signal-event %ld\" -ex \"continue\"' regtool set -W '/HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/AeDebug/Auto' 1","title":"Native Windows processes"},{"location":"wiki/JIT-Debugging/#native-windows-processes-started-from-msys2","text":"When a native process which was started (possibly indirectly) from an MSYS2 process (such as bash ) crashes, it does not invoke the registered debugger (or Windows Error Reporting), unless the SetErrorMode SEM_NOGPFAULTERRORBOX flag was cleared in the meantime ( SetErrorMode flags are inherited from a parent process by default). As of msys2-runtime 3.2.0-2 , it is possible to tell MSYS2 to create processes without inheriting its error mode flags by setting an MSYS environment variable setting: export MSYS = winjitdebug exec bash ./crashy.exe (note that the option needs to be set in the parent process, so bash needs to be restarted, assuming you are starting processes from bash ).","title":"Native Windows processes started from MSYS2"},{"location":"wiki/Launchers/","text":"You should not launch sh.exe directly as that doesn't start a login shell or set the correct environment variables for the type of shell that you want to use. Instead, your best choices are: msys2_shell.cmd , the improved multi-purpose batch file from the filesystem package . Run msys2_shell.cmd --help for usage. msys2.exe , mingw64.exe , mingw32.exe , the new pinnable launchers from the msys2-launcher package from @Elieux. GitHub , discussion , discussion A nice explanation how to set up ConEmu to run MSYS2 inside it by jstine. Configuration for an MSYS2 shell in Visual Studio Code . msys2_env.bat from @DavidEGrayson. Gist , discussion msys2.cmd , mingw64.cmd , mingw32.cmd from @Elieux. Gist smart_msys from @jhasse. GitHub , discussion MSYS2 here , MINGW64 here and MINGW32 here Explorer context menu items from @Elieux. Gist msystem.bat and cmd/clink integration in the filesystem-cmd package from @userzimmermann. PR , commits git-bash.exe and start-ssh-agent.cmd as part of the Git for Windows project from @dscho. GitHub , GitHub Open MSYS2 here from @magthe, with contributions from @sushovan-dw and @ryanpfeeley. Gist+discussion msys2_shell.bat , mingw64_shell.bat and mingw32_shell.bat , the old-school batch files from old versions of the filesystem package . The idea If you need to start a shell correctly, but none of the ways above suit you, devise your own way based on this knowledge: set MSYSTEM=... into the environment, with the value of either MSYS , MINGW32 , or MINGW64 then run a login shell The typical one-liner if your options are limited is C:\\\\msys64\\\\usr\\\\bin\\\\env MSYSTEM=MSYS /usr/bin/bash -li . Caveats: MSYS2 inherits multi-user capabilities from Cygwin and there is a notion of user's default shell. Not everyone's default shell is bash . To correctly figure out the default shell from outside (i.e. without directly calling the POSIX APIs), you can use this shell one-liner or an equivalent: getent passwd $(whoami) | cut -d: -f7 There are other environment variables that control MSYS2 at runtime or initialization. See the source of launchers above to figure them out if needed. You might need to set CHERE_INVOKING=1 for the shell to stay in the current working directory. If you need to run a specific command instead of an interactive shell, you still need to go through a login shell, e.g. ... /usr/bin/bash -lc python .","title":"Launchers"},{"location":"wiki/Launchers/#the-idea","text":"If you need to start a shell correctly, but none of the ways above suit you, devise your own way based on this knowledge: set MSYSTEM=... into the environment, with the value of either MSYS , MINGW32 , or MINGW64 then run a login shell The typical one-liner if your options are limited is C:\\\\msys64\\\\usr\\\\bin\\\\env MSYSTEM=MSYS /usr/bin/bash -li . Caveats: MSYS2 inherits multi-user capabilities from Cygwin and there is a notion of user's default shell. Not everyone's default shell is bash . To correctly figure out the default shell from outside (i.e. without directly calling the POSIX APIs), you can use this shell one-liner or an equivalent: getent passwd $(whoami) | cut -d: -f7 There are other environment variables that control MSYS2 at runtime or initialization. See the source of launchers above to figure them out if needed. You might need to set CHERE_INVOKING=1 for the shell to stay in the current working directory. If you need to run a specific command instead of an interactive shell, you still need to go through a login shell, e.g. ... /usr/bin/bash -lc python .","title":"The idea"},{"location":"wiki/MSYS2-installation/","text":"I. Downloading MSYS2 ships in the form of installers and base archives. They can be installed or extracted to any place on your computer, but you MUST use folder names that consist of only ascii characters and no spaces (also it makes good sense to put it in a path that doesn't use many characters due to PATH_MAX being 260; C:\\msys32 or C:\\msys64 is ideal). You can download the installers or base MSYS2 archives from the links below: 32-bit 64-bit Note: if you are using 64-bit Windows, there is no reason to use 32-bit MSYS2. Well, to be honest, there is one reason: you want to develop MSYS2 software (or contribute to MSYS2-packages) and want to test that the software/package also works on 32-bit MSYS2. When it comes to native software, 64-bit MSYS2 can be used to build, install and run both 32-bit and 64-bit variants. 64-bit MSYS2 software (practically speaking) never needs to be \"re-based\", giving a better user experience. II. Installation The installers and base archives only contain the tools necessary to 1) start MSYS2 2) update the pre-installed packages and 3) install new packages. After installing or extracting MSYS2 you should start MSYS2 by executing msys2_shell.cmd . (if you did not use an installer and this is first time running of MSYS2 after unpacking, then at this point it will create the files and settings necessary for it to function properly. After this initial run you MUST restart MSYS2 so that the settings are correct) Now you can update the base MSYS2 packages to their latest versions. MSYS2 comes with a ported version of the [Pacman][1] package manager (known from Arch Linux). III. Updating packages Partial upgrades (e.g. updating just pacman while not updating msys2-runtime ) are not supported and are expected to break stuff. Since pacman 5.0.1.6403, you can just: Run pacman -Syuu . Follow the instructions. Repeat this step until it says there are no packages to update. Since pacman 4.2.1.6187, there's an update-core script that helps you to update MSYS2 in the right way. To update your MSYS2 installation you need: Run update-core . If one of the packages is updated during script run you MUST restart MSYS2 Run pacman -Suu to update the rest of the packages (allowing downgrades). In older MSYS2 installations, follow these steps: Before updating you should synchronize your local package databases with the latest repositories: pacman -Sy This command connects to the remote repositories and downloads the package databases. The next step is to update the installed packages (do this initially and as often as you want thereafter): The 'normal' way ( don't do this ) would be to simply issue: pacman -Suu ... however, because all MSYS2 programs share the same address space for DLLs due to how MSYS2 (well, Cygwin) implements 'fork', updating bash, MSYS2 or Pacman itself can cause subsequent package updates to fail. For this reason, the safest procedure for updating MSYS2 is to do it in two stages; first those 'core' MSYS2 packages: pacman --needed -S bash pacman pacman-mirrors msys2-runtime ... if any packages got updated during this then you MUST restart MSYS2 because files that are provided by these packages will be in use and after update you can get fork errors - you need to exit all MSYS2 shells (and if using MSYS2 32bit, run autorebase.bat) then re-launch msys2_shell.bat Finally you can do an update of the remaining packages by issuing: pacman -Suu IV. General Package Management Installing new packages: pacman -S <package_names|package_groups> For example, pacman -S make gettext base-devel In this example is a package group which contains many packages. If you try to install a package group, Pacman will ask you whether you want to install one package from the group or all of the packages from the group. Removing packages: pacman -R <package_names|package_groups> Searching for packages: pacman -Ss <name_pattern> More on our Using packages wikipage . V. Issues and workarounds Please read \"III.\" above, carefully :-) We will continue working towards trouble-free updates. If you do run into failures to run post-install scripts, it's really nothing to panic about. Simply make a list of the packages that failed to install correctly, exit all your MSYS2 shells (make sure that they fully exit and no mintty/bash processes are running). Then launch a new MSYS2 shell, and issue: pacman -S <list-of-packages-that-failed-to-install> If you get error: failed to prepare transaction (could not satisfy dependencies) complaining about msys2-runtime-devel when you try to update the core, you need to update this package alongside msys2-runtime and the other core packages. Sometimes a package upgrade fails with failed to commit transaction (conflicting files) and some-pkg: /path/to/some/file exists in filesystem . If you're sure you didn't put the offending files there manually, move or delete the files and start the upgrade again. If your MSYS2 is unable to start after an upgrade, it's possible you just have some lingering MSYS2 processes (loaded with an older version of the runtime) that are conflicting with the processes you're trying to start. Hunt down these processes in your favorite task manager and kill them, or just reboot your system. After an update, you get error: GPGME error: No data then you were unlucky and caught SourceForge at a bad time. Check /var/lib/pacman/sync and if the files in there contain an HTML formatted error page, then delete those files and try again.","title":"MSYS2-Installation"},{"location":"wiki/MSYS2-installation/#i-downloading","text":"MSYS2 ships in the form of installers and base archives. They can be installed or extracted to any place on your computer, but you MUST use folder names that consist of only ascii characters and no spaces (also it makes good sense to put it in a path that doesn't use many characters due to PATH_MAX being 260; C:\\msys32 or C:\\msys64 is ideal). You can download the installers or base MSYS2 archives from the links below: 32-bit 64-bit Note: if you are using 64-bit Windows, there is no reason to use 32-bit MSYS2. Well, to be honest, there is one reason: you want to develop MSYS2 software (or contribute to MSYS2-packages) and want to test that the software/package also works on 32-bit MSYS2. When it comes to native software, 64-bit MSYS2 can be used to build, install and run both 32-bit and 64-bit variants. 64-bit MSYS2 software (practically speaking) never needs to be \"re-based\", giving a better user experience.","title":"I. Downloading"},{"location":"wiki/MSYS2-installation/#ii-installation","text":"The installers and base archives only contain the tools necessary to 1) start MSYS2 2) update the pre-installed packages and 3) install new packages. After installing or extracting MSYS2 you should start MSYS2 by executing msys2_shell.cmd . (if you did not use an installer and this is first time running of MSYS2 after unpacking, then at this point it will create the files and settings necessary for it to function properly. After this initial run you MUST restart MSYS2 so that the settings are correct) Now you can update the base MSYS2 packages to their latest versions. MSYS2 comes with a ported version of the [Pacman][1] package manager (known from Arch Linux).","title":"II. Installation"},{"location":"wiki/MSYS2-installation/#iii-updating-packages","text":"Partial upgrades (e.g. updating just pacman while not updating msys2-runtime ) are not supported and are expected to break stuff. Since pacman 5.0.1.6403, you can just: Run pacman -Syuu . Follow the instructions. Repeat this step until it says there are no packages to update. Since pacman 4.2.1.6187, there's an update-core script that helps you to update MSYS2 in the right way. To update your MSYS2 installation you need: Run update-core . If one of the packages is updated during script run you MUST restart MSYS2 Run pacman -Suu to update the rest of the packages (allowing downgrades). In older MSYS2 installations, follow these steps: Before updating you should synchronize your local package databases with the latest repositories: pacman -Sy This command connects to the remote repositories and downloads the package databases. The next step is to update the installed packages (do this initially and as often as you want thereafter): The 'normal' way ( don't do this ) would be to simply issue: pacman -Suu ... however, because all MSYS2 programs share the same address space for DLLs due to how MSYS2 (well, Cygwin) implements 'fork', updating bash, MSYS2 or Pacman itself can cause subsequent package updates to fail. For this reason, the safest procedure for updating MSYS2 is to do it in two stages; first those 'core' MSYS2 packages: pacman --needed -S bash pacman pacman-mirrors msys2-runtime ... if any packages got updated during this then you MUST restart MSYS2 because files that are provided by these packages will be in use and after update you can get fork errors - you need to exit all MSYS2 shells (and if using MSYS2 32bit, run autorebase.bat) then re-launch msys2_shell.bat Finally you can do an update of the remaining packages by issuing: pacman -Suu","title":"III. Updating packages"},{"location":"wiki/MSYS2-installation/#iv-general-package-management","text":"Installing new packages: pacman -S <package_names|package_groups> For example, pacman -S make gettext base-devel In this example is a package group which contains many packages. If you try to install a package group, Pacman will ask you whether you want to install one package from the group or all of the packages from the group. Removing packages: pacman -R <package_names|package_groups> Searching for packages: pacman -Ss <name_pattern> More on our Using packages wikipage .","title":"IV. General Package Management"},{"location":"wiki/MSYS2-installation/#v-issues-and-workarounds","text":"Please read \"III.\" above, carefully :-) We will continue working towards trouble-free updates. If you do run into failures to run post-install scripts, it's really nothing to panic about. Simply make a list of the packages that failed to install correctly, exit all your MSYS2 shells (make sure that they fully exit and no mintty/bash processes are running). Then launch a new MSYS2 shell, and issue: pacman -S <list-of-packages-that-failed-to-install> If you get error: failed to prepare transaction (could not satisfy dependencies) complaining about msys2-runtime-devel when you try to update the core, you need to update this package alongside msys2-runtime and the other core packages. Sometimes a package upgrade fails with failed to commit transaction (conflicting files) and some-pkg: /path/to/some/file exists in filesystem . If you're sure you didn't put the offending files there manually, move or delete the files and start the upgrade again. If your MSYS2 is unable to start after an upgrade, it's possible you just have some lingering MSYS2 processes (loaded with an older version of the runtime) that are conflicting with the processes you're trying to start. Hunt down these processes in your favorite task manager and kill them, or just reboot your system. After an update, you get error: GPGME error: No data then you were unlucky and caught SourceForge at a bad time. Check /var/lib/pacman/sync and if the files in there contain an HTML formatted error page, then delete those files and try again.","title":"V. Issues and workarounds"},{"location":"wiki/MSYS2-introduction/","text":"MSYS2 is software distribution and a building platform for Windows. It provides a Unix-like environment, a command-line interface and a software repository making it easier to install, use, build and port software on Windows. That means Bash, Autotools, Make, Git, GCC, GDB..., all easily installable through Pacman, a fully-featured package manager. It is an independent rewrite of MSys, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 with the aim of better interoperability with native Windows software. Both 32-bit and 64-bit variants exist and receive mostly the same level of support. Here is a list of packages we provide . Subsystems MSYS2 consists of three subsystems and their corresponding package repositories, msys2 , mingw32 , and mingw64 . The mingw subsystems provide native Windows programs and are the main focus of the project. These programs are built to co-operate well with other Windows programs, independently of the other subsystems. This part builds on the MinGW-w64 project. The msys2 subsystem provides an emulated mostly-POSIX-compliant environment for building software, package management, and shell scripting. These programs live in a virtual single-root filesystem (the root is the MSYS2 installation directory). Some effort is made to have the programs work well with native Windows programs, but it's not seamless. This part builds on the Cygwin project. Each of the subsystems provides its own native (i.e. target=host ) compiler toolchain, in msys2-devel , mingw-w64-i686-toolchain , and mingw-w64-x86_64-toolchain . There are also cross compiler toolchains with host={i686,x86_64}-pc-msys and target={i686,x86_64}-w64-mingw32 in mingw-w64-cross-toolchain , but these are of limited use because there are no library packages for them. Shells Every subsystem has an associated \"shell\", which is essentially a set of environment variables that allow the subsystems to co-operate properly. These shells can be invoked using launchers in the MSYS2 installation directory or using the shortcuts in the Windows Start menu. The launchers set the MSYSTEM variable and open a terminal window ( mintty ) with a proper shell ( bash ). Bash in turn sources /etc/profile which sets the environment depending on the value of MSYSTEM . Without the correct environment, various things may and will (sometimes silently) break. The exception is using mingw subsystems from pure Windows, which shouldn't require any special environment apart from an entry in PATH . Do not set MSYSTEM outside of the shells, because that will also break things. PATH For optimal usage, MSYS2 automatically strips your PATH environment variable, essentially only leaving C:\\Windows\\System32 and few others. This behavior can be controlled by setting the variable MSYS2_PATH_TYPE before starting a shell or using a correct argument when executing the launcher script. Beware that mixing in programs from other MSYS2 installations, Cygwin installations, compiler toolchains or even various other programs is not supported and will probably break things in unexpected ways. Do not have these things in PATH when running MSYS2 unless you know what you're doing. Use msys2 shell for running pacman , makepkg , makepkg-mingw and for building POSIX-dependent software that you don't intend to distribute. Use mingw shells for building native Windows software and other tasks. Packages MSYS2 uses a port of pacman (known from Arch Linux) for package management. This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system ( makepkg-mingw ) - which is used to make these packages. Packages for msys2 are built from recipes in the msys2-packages Git repository, packages for mingw are in mingw-packages . Official repositories are on GitHub under user the msys2 organization. When looking for msys2 packages or deciding to create a new one, keep in mind that MSYS2 doesn't intend to compete with Cygwin or duplicate their efforts. The set of things that belong to the msys2 subsystem is pretty small and needs to stay that way. You might be wondering why there appears to be only one architecture variant of the msys2 repository. In reality there are two, but the decision about which one to use is made at the time you install it, depending on whether you installed the i686 or the x86_64 version. It is possible to install both if you wish. Actually, you can have multiple installations of each on your computer, but you should never run programs from two different MSYS2 XXbit variants at the same time due to DLL address space and version conflicts. Also note that the uninstaller will only remove the most recently installed one of each variant). File system The virtual filesystem contains: Paths Contents /bin , /dev , /home , /opt , /proc , /tmp , /var essential POSIX stuff /etc , /usr msys2 subsystem /mingw32 , /mingw64 mingw subsystems /c , /d , ... mount points for Windows drives /*.xml , /maintenancetool.* , InstallationLog.txt (un)installer /autorebase.bat , /msys2_shell.cmd , /msys2.ico shell entry points","title":"MSYS2-Introduction"},{"location":"wiki/MSYS2-introduction/#subsystems","text":"MSYS2 consists of three subsystems and their corresponding package repositories, msys2 , mingw32 , and mingw64 . The mingw subsystems provide native Windows programs and are the main focus of the project. These programs are built to co-operate well with other Windows programs, independently of the other subsystems. This part builds on the MinGW-w64 project. The msys2 subsystem provides an emulated mostly-POSIX-compliant environment for building software, package management, and shell scripting. These programs live in a virtual single-root filesystem (the root is the MSYS2 installation directory). Some effort is made to have the programs work well with native Windows programs, but it's not seamless. This part builds on the Cygwin project. Each of the subsystems provides its own native (i.e. target=host ) compiler toolchain, in msys2-devel , mingw-w64-i686-toolchain , and mingw-w64-x86_64-toolchain . There are also cross compiler toolchains with host={i686,x86_64}-pc-msys and target={i686,x86_64}-w64-mingw32 in mingw-w64-cross-toolchain , but these are of limited use because there are no library packages for them.","title":"Subsystems"},{"location":"wiki/MSYS2-introduction/#shells","text":"Every subsystem has an associated \"shell\", which is essentially a set of environment variables that allow the subsystems to co-operate properly. These shells can be invoked using launchers in the MSYS2 installation directory or using the shortcuts in the Windows Start menu. The launchers set the MSYSTEM variable and open a terminal window ( mintty ) with a proper shell ( bash ). Bash in turn sources /etc/profile which sets the environment depending on the value of MSYSTEM . Without the correct environment, various things may and will (sometimes silently) break. The exception is using mingw subsystems from pure Windows, which shouldn't require any special environment apart from an entry in PATH . Do not set MSYSTEM outside of the shells, because that will also break things.","title":"Shells"},{"location":"wiki/MSYS2-introduction/#path","text":"For optimal usage, MSYS2 automatically strips your PATH environment variable, essentially only leaving C:\\Windows\\System32 and few others. This behavior can be controlled by setting the variable MSYS2_PATH_TYPE before starting a shell or using a correct argument when executing the launcher script. Beware that mixing in programs from other MSYS2 installations, Cygwin installations, compiler toolchains or even various other programs is not supported and will probably break things in unexpected ways. Do not have these things in PATH when running MSYS2 unless you know what you're doing. Use msys2 shell for running pacman , makepkg , makepkg-mingw and for building POSIX-dependent software that you don't intend to distribute. Use mingw shells for building native Windows software and other tasks.","title":"PATH"},{"location":"wiki/MSYS2-introduction/#packages","text":"MSYS2 uses a port of pacman (known from Arch Linux) for package management. This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system ( makepkg-mingw ) - which is used to make these packages. Packages for msys2 are built from recipes in the msys2-packages Git repository, packages for mingw are in mingw-packages . Official repositories are on GitHub under user the msys2 organization. When looking for msys2 packages or deciding to create a new one, keep in mind that MSYS2 doesn't intend to compete with Cygwin or duplicate their efforts. The set of things that belong to the msys2 subsystem is pretty small and needs to stay that way. You might be wondering why there appears to be only one architecture variant of the msys2 repository. In reality there are two, but the decision about which one to use is made at the time you install it, depending on whether you installed the i686 or the x86_64 version. It is possible to install both if you wish. Actually, you can have multiple installations of each on your computer, but you should never run programs from two different MSYS2 XXbit variants at the same time due to DLL address space and version conflicts. Also note that the uninstaller will only remove the most recently installed one of each variant).","title":"Packages"},{"location":"wiki/MSYS2-introduction/#file-system","text":"The virtual filesystem contains: Paths Contents /bin , /dev , /home , /opt , /proc , /tmp , /var essential POSIX stuff /etc , /usr msys2 subsystem /mingw32 , /mingw64 mingw subsystems /c , /d , ... mount points for Windows drives /*.xml , /maintenancetool.* , InstallationLog.txt (un)installer /autorebase.bat , /msys2_shell.cmd , /msys2.ico shell entry points","title":"File system"},{"location":"wiki/MSYS2-reinstallation/","text":"Introduction When we release new installers and new base tar.zst packages, we'd appreciate it if people can help out by testing complete re-installs of their entire MSYS2. The procedure is safe as it is fully reversible. Also, if your system gets messed up, this procedure could help to get you running again. Re-installing Run your existing MSYS2 installation via msys2_shell.cmd . Make a list of installed packages: pacman - Qqe | xargs echo > / c / packages . txt ; exit Rename your msys?? folder to msys??.old . Run the installer (or untar the base package, run msys2_shell.cmd , then exit it). To save server bandwidth and your time, move your old cached packages directory to the new installation. In Explorer, remove the empty msys??\\var\\cache\\pacman\\pkg folder, then replace it with msys??.old\\var\\cache\\pacman\\pkg . Run the new MSYS2 installation via msys2_shell.cmd . Update the package databases: pacman -Sy Update the core packages: pacman --needed -S bash pacman pacman-mirrors msys2-runtime If any packages got updated during step 8, you MUST restart MSYS2, otherwise you can get fork errors in the next step. You need to exit all MSYS2 shells (and if using MSYS2 32bit, run autorebase.bat ) then re-launch msys2_shell.cmd . Re-install your old packages, by entering: pacman -S --needed $(cat /c/packages.txt) You may also want to compare your new $HOME folder with your old one and merge across your dotfiles and other files. Reversing the procedure Move the pkg folder back from msys??\\var\\cache\\pacman\\pkg to msys??.old\\var\\cache\\pacman\\pkg . Delete the new msys?? folder. Rename msys??.old to msys?? . Finally It would be good if you can try working with the new installation to see if everything's OK, and if not, please report a bug (try to use e.g. strace or procmon to figure out what goes wrong and meld3 or Beyond Compare to help track down which files are different).","title":"Re-installing MSYS2"},{"location":"wiki/MSYS2-reinstallation/#introduction","text":"When we release new installers and new base tar.zst packages, we'd appreciate it if people can help out by testing complete re-installs of their entire MSYS2. The procedure is safe as it is fully reversible. Also, if your system gets messed up, this procedure could help to get you running again.","title":"Introduction"},{"location":"wiki/MSYS2-reinstallation/#re-installing","text":"Run your existing MSYS2 installation via msys2_shell.cmd . Make a list of installed packages: pacman - Qqe | xargs echo > / c / packages . txt ; exit Rename your msys?? folder to msys??.old . Run the installer (or untar the base package, run msys2_shell.cmd , then exit it). To save server bandwidth and your time, move your old cached packages directory to the new installation. In Explorer, remove the empty msys??\\var\\cache\\pacman\\pkg folder, then replace it with msys??.old\\var\\cache\\pacman\\pkg . Run the new MSYS2 installation via msys2_shell.cmd . Update the package databases: pacman -Sy Update the core packages: pacman --needed -S bash pacman pacman-mirrors msys2-runtime If any packages got updated during step 8, you MUST restart MSYS2, otherwise you can get fork errors in the next step. You need to exit all MSYS2 shells (and if using MSYS2 32bit, run autorebase.bat ) then re-launch msys2_shell.cmd . Re-install your old packages, by entering: pacman -S --needed $(cat /c/packages.txt) You may also want to compare your new $HOME folder with your old one and merge across your dotfiles and other files.","title":"Re-installing"},{"location":"wiki/MSYS2-reinstallation/#reversing-the-procedure","text":"Move the pkg folder back from msys??\\var\\cache\\pacman\\pkg to msys??.old\\var\\cache\\pacman\\pkg . Delete the new msys?? folder. Rename msys??.old to msys?? .","title":"Reversing the procedure"},{"location":"wiki/MSYS2-reinstallation/#finally","text":"It would be good if you can try working with the new installation to see if everything's OK, and if not, please report a bug (try to use e.g. strace or procmon to figure out what goes wrong and meld3 or Beyond Compare to help track down which files are different).","title":"Finally"},{"location":"wiki/Mirrors/","text":"Move to here","title":"Creating a Mirror"},{"location":"wiki/Packages/","text":"#!/bin/sh ###### This is a pacman dump of all the packages we provide as of _-_. The commands used to re-generate this list are listed below. LANG = C { cat \" $0 \" | sed -r \\ -e \"s/_([0-9-]+)_/_ $( date +%Y-%m-%d ) _/\" \\ -e '/^## /q' echo { pacman -Ss | grep '^mingw64/' -A 1 pacman -Ss | grep '^msys/' -A 1 } | sed -r \\ -e 's/ \\[installed.*\\]//' \\ -e 's#^mingw64/([^ ]+)#<br/>mingw/<b>\\1</b>#' \\ -e 's#^msys/([^ ]+)#<br/>msys/<b>\\1</b>#' \\ -e 's/-x86_64//' \\ -e 's/$/<br\\/>/' \\ -e 's/~/:/' } > \" $0 _\" mv \" $0 _\" \" $0 \" exit The list There is a nicer package list on packages.msys2.org .","title":"Packages List"},{"location":"wiki/Packages/#the-list","text":"There is a nicer package list on packages.msys2.org .","title":"The list"},{"location":"wiki/Porting/","text":"While in our humble opinions, MSYS2 makes collaborative, organised development of open-source software on Windows a workable proposition, there are a few things to be aware of that we commonly run into, mostly due to the design decisions made by Microsoft, our preference for using native tools and compilers rather than cross msys2-to-native ones and our wish to be as flexible as we can be. mingw32-make MSYS2 provides two versions of make, one in the make package and one in the mingw-w64-{i686,x86_64}-make packages. The latter one is called mingw32-make on command line, is fully native and doesn't depend on msys2 shells. The downside is that it doesn't work with many Makefile s. Unless you know what you're doing, use the regular make . Detecting version of MSYS from GNU make You can use the following Makefile snippet to detect whether you are running GNU make from an MSYS or an MSYS2 shell. If you run it through mingw32-make.exe from cmd.exe you will likely get an error since uname will not be found on your PATH . If you run it through mingw32-make.exe from one of the MSYS shells, it will set msys_version to 1 or 2 as appropriate. On any other system with uname present, it will set it to 0. msys_version := $(if $(findstring Msys, $(shell uname -o)),$(word 1, $(subst ., ,$(shell uname -r))),0) $(info The version of MSYS you are running is $(msys_version) (0 meaning not MSYS at all)) Platform checks You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers: Identifier Platform(s) Usage _WIN32 mingw, msvc C code ( #ifdef ... ) _WIN64 64-bit mingw, 64-bit msvc C code ( #ifdef ... ) __CYGWIN__ msys2, cygwin C code ( #ifdef ... ) __MSYS__ msys2 C code ( #ifdef ... ) x86_64-pc-msys2 64-bit msys2 Build scripts ( if [ $host = '...' ] ) i686-pc-msys2 32-bit msys2 Build scripts ( if [ $host = '...' ] ) x86_64-w64-mingw32 64-bit mingw Build scripts ( if [ $host = '...' ] ) i686-w64-mingw32 32-bit mingw Build scripts ( if [ $host = '...' ] ) msys msys2 Python ( sys.platform ) win32 mingw Python ( sys.platform ) Filesystem namespaces In MSYS2 there are two different filesystem namespaces in play. If you are building purely msys2 software, you can ignore the Windows filesystem namespace entirely, however, when building native software using MSYS2's tools, you must be mindful that when msys2 executes a native program, it will translate environment variables and command arguments from msys2-form to native-form. To do this, it converts things that look like msys2 paths. Sometimes it gets this wrong, e.g.: command.exe /switch Explanation: /switch is a Windows style switch. Note that Windows programs commonly accept unambiguous dash-prefixed switches ( -switch ) as well. adb push readme.txt /sdcard/0/ Explanation: /sdcard/0/ is a path on a foreign system. ./configure --root=/ Explanation: The value of root ( / ) is emitted to a text file via echo (which is an msys2 program and hence not mangled) and also to a Makefile (through autotools) which passes it to a native program, which reads the text file replacing each instance of / with \"some-other-path\". This will go wrong as / passed to the native program was converted to e.g. C:/msys64/ and therefore the necessary substitutions did not happen. [last sentence needs review or rewording] To work around this, path conversion can be selectively disabled. MSYS2 reads an environment variable called MSYS2_ARG_CONV_EXCL . This is a ; delimited string each part of which is compared against the front part of each argument and if a match is found, that conversion is skipped. An example of a value for MSYS2_ARG_CONV_EXCL that would inhibit path transformations of the 3 cases above is /switch;/sdcard;--root= . Setting MSYS2_ARG_CONV_EXCL=* prevents any path transformation. The development repository for this path conversion code is https://github.com/Alexpux/path_convert . If you find a case that you think is unambiguously being converted incorrectly, please raise an issue there and/or a pull request with the broken test-case. Hard-coded paths and relocation When installing MSYS2, the user selects the root folder. POSIX software has a habit of baking the installation paths into the packages at build time, which is okay for msys2 software (which only sees the single-root virtual filesystem), but usually causes failures in native software. When a program tries to load its data files using these absolute paths on another MSYS2 installed to a different root folder, it won't find them. For this reason, adding path relocation patches is a common necessity for mingw packages (but never for msys2 packages). The point is to find the path where the program's executable resides, cutting off the /bin from the end and finding all necessary files using paths relative to that. Since this is a pretty common task and is not exactly trivial to get it right for all cases, we wrote some re-usable C code for that, available at https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-pathtools . Sometimes these paths are baked into shell scripts or pkg-config's .pc files. In that case, you should use sed in the PKGBUILD package() function to correct this back to the msys2 version of the path. [please review last sentence] An example of this can be seen at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libtool/PKGBUILD#L55 . C *printf Format Specifier issues The vc6.0 msvcrt.dll that MinGW-w64 targets doesn't implement support for the ANSI standard format specifiers. MinGW-w64 works around this by providing their own implementation. To enable this you should pass -D__USE_MINGW_ANSI_STDIO=1 to the MinGW-w64 C and C++ compilers. All of our C/C++ packages are built with this flag. Different size of struct timeval The Windows (and thus mingw-w64) struct timeval is defined as having two long members, while the POSIX specs say it's supposed to have one time_t and one suseconds_t member. This means that on 64-bit, the size of the struct will be different from what you would expect on Linux/Cygwin/MSYS2. struct timeval on MSDN struct timeval on OpenGroup.org More 32/64 bit peculiarities Sorting out the stat thing by LRN: https://archive.li/IsgPq (Original URL - now down: https://gnunet.org/sorting-out-stat-thing ) Calling conventions, stdcall, and autotools Details about Windows' 32bit calling conventions: http://www.willus.com/mingw/yongweiwu_stdcall.html Problems stdcall causes with autotool's AC_CHECK_FUNC and AC_SEARCH_LIBS: http://lists.gnu.org/archive/html/autoconf/2013-05/msg00090.html Macro/inline function and autotools AC_CHECK_FUNCS and friends can't deal with function macros and static inline functions (because the checking code tries to #undef the symbol, doesn't include any headers and declares the symbol as extern instead). Possible solution is replacing them with more elaborate checks using AC_LINK_IFELSE or AC_COMPILE_IFELSE . For example this: AC_CHECK_FUNCS ( [ localtime_r ] , [ AM_CONDITIONAL([HAVE_LOCALTIME_R ] , true ) ] , [ AM_CONDITIONAL([HAVE_LOCALTIME_R ] , false ) ] ) ... can be replaced with this: AC_MSG_CHECKING ([ for localtime_r ]) AC_LINK_IFELSE ([ AC_LANG_PROGRAM ([[ #include <time.h> ]], [[ time_t t ; struct tm r ; localtime_r ( & t , & r ); ]])], [ AC_MSG_RESULT ([ yes ]) AM_CONDITIONAL ([ HAVE_LOCALTIME_R ], true ) AC_DEFINE ([ HAVE_LOCALTIME_R ], [ 1 ], [ Define to 1 if you have the ` localtime_r ' function or macro .])], [ AC_MSG_RESULT ([ no ]) AM_CONDITIONAL ([ HAVE_LOCALTIME_R ], false )]) Don't forget to autoreconf -fi after patching configure.ac . A tidy workaround from flameeyes for asprintf/vasprintf (but generally applicable): https://mailman.videolan.org/pipermail/vlc-devel/2015-March/101802.html Guarded time functions, ANSI format specifiers Some things in mingw-w64 are (maybe unexpectedly) guarded by #ifdef s. Check out _POSIX_C_SOURCE , __USE_MINGW_ANSI_STDIO , the time.h file. Note that (at the time of writing) pthread.h contains some defines that affect the definitions in time.h . Undefined references and linking to DLLs/SOs [this section may contain misinformations; it needs review from a knowledgeable person] Linux/ELF platforms generally don't do anything special to link to shared objects, they just leave the undefined references in the binary. Windows however requires all references to be resolved at link time. In case of DLLs, this is solved by the .dll.a import libraries that add the relevant .dll to the binary's import table and insert correct calls into the code, but it needs that correct linker flags be passed when linking binaries. Note that the linker is aware of these files and will use them automatically when using the standard -l arguments, for example -lfoo will make the linker check for libfoo.dll.a and libfoo.a , in this order (unless specified otherwise). Libtool generally refuses to create DLLs unless -no-undefined is passed to the linker invocation ( library_la_LDFLAGS = -no-undefined ). See: https://lists.gnu.org/archive/html/libtool/2007-04/msg00066.html Library prefixes mingw DLLs follow the convention of prefixing libraries with lib . This affects shared libraries ( .dll ), static object archives ( .a ), and DLL import libraries ( .dll.a ). Because msys2 DLLs are generally ABI-incompatible with everything from outside of msys2 , they are prefixed with msys2- instead. For completeness, we note that Cygwin DLLs are prefixed with cyg . [does libtool or the linker handle this automatically?] Standard streams in mintty mintty is primarily designed to be a good terminal emulator (in the POSIX sense of the word) and it works well with bash, ssh and other Cygwin/MSYS2 programs. Because native Windows console programs use a fundamentally different way of handling console input/output, mintty uses pipes to connect to their standard streams (stdin, stdout, stderr). Unfortunately, this has the effect that isatty and similar APIs (used to check whether a stream is attached to an interactive console or a pipe/file) will return incorrect values for native programs running under mintty. One way of fixing this problem is to run native programs inside a real Windows console, hide the console and use the console API to communicate with the program. This approach has obvious disadvantages, but it's good enough. Actually, this is the way most Windows console emulators work (e.g. ConsoleZ, ConEmu). There is also a wrapper program called winpty that does exactly this and translates the I/O to/from standard terminal sequences which mintty understands. Running a program under winpty (by prefixing the command line with winpty ) will make the program think it is running interactively, but it will also break any special features depending on terminal sequences, possibly including colored text output and TUIs. MSYS2 includes wrappers for some affected programs, so that they will work correctly most of the time. Examples can be seen in packages containing REPLs (python3, lua, nodejs, ...). mintty issue #56 , original on Google Code winpty on GitHub Signals in mintty When running a native Windows program in mintty (or urxvt, apparently), Ctrl+C will not be correctly passed to the process. Instead, it seems to be eaten by the terminal and the running process is terminated. ticket #135 Paths in mingw Python The mingw python provided by MSYS2 will try to produce paths that are right for the environment it's running in. According to the value of MSYSTEM , it will use either forward or backward slashes as os.path.sep . Response files When passing arguments with absolute paths to native Windows programs (such as /mingw64/bin/gcc ), these paths get (in most cases) automatically converted by MSYS2 if they're in POSIX format. However, if you're passing these paths inside a file (e.g. a response file for GCC -- gcc @somefile ), they need to be pre-converted to Windows native format. discussion topic: gcc -I (eye) uses msys2 path or windows path? Setting floating point precision Floating point precision issues with multiple threads: gfortran, open mp and floating point precision by Carl Kleffner: https://sourceforge.net/p/mingw-w64/mailman/message/33332276/ https://gcc.gnu.org/wiki/FloatingPointMath https://gcc.gnu.org/wiki/x87note Command line parsing Windows programs parse the command line themselves, it isn't parsed for them by the calling process, as on Linux. This means that if wildcards (glob patterns) are to be accepted by the program, it has to be able to expand them somehow. MinGW-w64 supplies the correct start-up code, so it happens automatically, in a manner compatible with MSVC-compiled programs. If undesirable, the behavior can be disabled at program build. Cygwin/MSYS2 programs have to deal with a mix of both approaches, but they can apparently deal with it. Note that they don't behave exactly like native programs, for example they understand single-quoted arguments. \"How Command Line Parameters Are Parsed\" by David Deley \"Everyone quotes command line arguments the wrong way\" by Daniel Colascione Other resources A collection of articles on general C and C++ topics. http://locklessinc.com/articles/ The MinGW-w64 project's wiki. http://sourceforge.net/p/mingw-w64/wiki2/browse_pages/","title":"Porting"},{"location":"wiki/Porting/#mingw32-make","text":"MSYS2 provides two versions of make, one in the make package and one in the mingw-w64-{i686,x86_64}-make packages. The latter one is called mingw32-make on command line, is fully native and doesn't depend on msys2 shells. The downside is that it doesn't work with many Makefile s. Unless you know what you're doing, use the regular make .","title":"mingw32-make"},{"location":"wiki/Porting/#detecting-version-of-msys-from-gnu-make","text":"You can use the following Makefile snippet to detect whether you are running GNU make from an MSYS or an MSYS2 shell. If you run it through mingw32-make.exe from cmd.exe you will likely get an error since uname will not be found on your PATH . If you run it through mingw32-make.exe from one of the MSYS shells, it will set msys_version to 1 or 2 as appropriate. On any other system with uname present, it will set it to 0. msys_version := $(if $(findstring Msys, $(shell uname -o)),$(word 1, $(subst ., ,$(shell uname -r))),0) $(info The version of MSYS you are running is $(msys_version) (0 meaning not MSYS at all))","title":"Detecting version of MSYS from GNU make"},{"location":"wiki/Porting/#platform-checks","text":"You may need to use platform checks to switch between behaviour suited for MSYS2 and the default one. Some useful identifiers: Identifier Platform(s) Usage _WIN32 mingw, msvc C code ( #ifdef ... ) _WIN64 64-bit mingw, 64-bit msvc C code ( #ifdef ... ) __CYGWIN__ msys2, cygwin C code ( #ifdef ... ) __MSYS__ msys2 C code ( #ifdef ... ) x86_64-pc-msys2 64-bit msys2 Build scripts ( if [ $host = '...' ] ) i686-pc-msys2 32-bit msys2 Build scripts ( if [ $host = '...' ] ) x86_64-w64-mingw32 64-bit mingw Build scripts ( if [ $host = '...' ] ) i686-w64-mingw32 32-bit mingw Build scripts ( if [ $host = '...' ] ) msys msys2 Python ( sys.platform ) win32 mingw Python ( sys.platform )","title":"Platform checks"},{"location":"wiki/Porting/#filesystem-namespaces","text":"In MSYS2 there are two different filesystem namespaces in play. If you are building purely msys2 software, you can ignore the Windows filesystem namespace entirely, however, when building native software using MSYS2's tools, you must be mindful that when msys2 executes a native program, it will translate environment variables and command arguments from msys2-form to native-form. To do this, it converts things that look like msys2 paths. Sometimes it gets this wrong, e.g.: command.exe /switch Explanation: /switch is a Windows style switch. Note that Windows programs commonly accept unambiguous dash-prefixed switches ( -switch ) as well. adb push readme.txt /sdcard/0/ Explanation: /sdcard/0/ is a path on a foreign system. ./configure --root=/ Explanation: The value of root ( / ) is emitted to a text file via echo (which is an msys2 program and hence not mangled) and also to a Makefile (through autotools) which passes it to a native program, which reads the text file replacing each instance of / with \"some-other-path\". This will go wrong as / passed to the native program was converted to e.g. C:/msys64/ and therefore the necessary substitutions did not happen. [last sentence needs review or rewording] To work around this, path conversion can be selectively disabled. MSYS2 reads an environment variable called MSYS2_ARG_CONV_EXCL . This is a ; delimited string each part of which is compared against the front part of each argument and if a match is found, that conversion is skipped. An example of a value for MSYS2_ARG_CONV_EXCL that would inhibit path transformations of the 3 cases above is /switch;/sdcard;--root= . Setting MSYS2_ARG_CONV_EXCL=* prevents any path transformation. The development repository for this path conversion code is https://github.com/Alexpux/path_convert . If you find a case that you think is unambiguously being converted incorrectly, please raise an issue there and/or a pull request with the broken test-case.","title":"Filesystem namespaces"},{"location":"wiki/Porting/#hard-coded-paths-and-relocation","text":"When installing MSYS2, the user selects the root folder. POSIX software has a habit of baking the installation paths into the packages at build time, which is okay for msys2 software (which only sees the single-root virtual filesystem), but usually causes failures in native software. When a program tries to load its data files using these absolute paths on another MSYS2 installed to a different root folder, it won't find them. For this reason, adding path relocation patches is a common necessity for mingw packages (but never for msys2 packages). The point is to find the path where the program's executable resides, cutting off the /bin from the end and finding all necessary files using paths relative to that. Since this is a pretty common task and is not exactly trivial to get it right for all cases, we wrote some re-usable C code for that, available at https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-pathtools . Sometimes these paths are baked into shell scripts or pkg-config's .pc files. In that case, you should use sed in the PKGBUILD package() function to correct this back to the msys2 version of the path. [please review last sentence] An example of this can be seen at https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-libtool/PKGBUILD#L55 .","title":"Hard-coded paths and relocation"},{"location":"wiki/Porting/#c-printf-format-specifier-issues","text":"The vc6.0 msvcrt.dll that MinGW-w64 targets doesn't implement support for the ANSI standard format specifiers. MinGW-w64 works around this by providing their own implementation. To enable this you should pass -D__USE_MINGW_ANSI_STDIO=1 to the MinGW-w64 C and C++ compilers. All of our C/C++ packages are built with this flag.","title":"C *printf Format Specifier issues"},{"location":"wiki/Porting/#different-size-of-struct-timeval","text":"The Windows (and thus mingw-w64) struct timeval is defined as having two long members, while the POSIX specs say it's supposed to have one time_t and one suseconds_t member. This means that on 64-bit, the size of the struct will be different from what you would expect on Linux/Cygwin/MSYS2. struct timeval on MSDN struct timeval on OpenGroup.org","title":"Different size of struct timeval"},{"location":"wiki/Porting/#more-3264-bit-peculiarities","text":"Sorting out the stat thing by LRN: https://archive.li/IsgPq (Original URL - now down: https://gnunet.org/sorting-out-stat-thing )","title":"More 32/64 bit peculiarities"},{"location":"wiki/Porting/#calling-conventions-stdcall-and-autotools","text":"Details about Windows' 32bit calling conventions: http://www.willus.com/mingw/yongweiwu_stdcall.html Problems stdcall causes with autotool's AC_CHECK_FUNC and AC_SEARCH_LIBS: http://lists.gnu.org/archive/html/autoconf/2013-05/msg00090.html","title":"Calling conventions, stdcall, and autotools"},{"location":"wiki/Porting/#macroinline-function-and-autotools","text":"AC_CHECK_FUNCS and friends can't deal with function macros and static inline functions (because the checking code tries to #undef the symbol, doesn't include any headers and declares the symbol as extern instead). Possible solution is replacing them with more elaborate checks using AC_LINK_IFELSE or AC_COMPILE_IFELSE . For example this: AC_CHECK_FUNCS ( [ localtime_r ] , [ AM_CONDITIONAL([HAVE_LOCALTIME_R ] , true ) ] , [ AM_CONDITIONAL([HAVE_LOCALTIME_R ] , false ) ] ) ... can be replaced with this: AC_MSG_CHECKING ([ for localtime_r ]) AC_LINK_IFELSE ([ AC_LANG_PROGRAM ([[ #include <time.h> ]], [[ time_t t ; struct tm r ; localtime_r ( & t , & r ); ]])], [ AC_MSG_RESULT ([ yes ]) AM_CONDITIONAL ([ HAVE_LOCALTIME_R ], true ) AC_DEFINE ([ HAVE_LOCALTIME_R ], [ 1 ], [ Define to 1 if you have the ` localtime_r ' function or macro .])], [ AC_MSG_RESULT ([ no ]) AM_CONDITIONAL ([ HAVE_LOCALTIME_R ], false )]) Don't forget to autoreconf -fi after patching configure.ac . A tidy workaround from flameeyes for asprintf/vasprintf (but generally applicable): https://mailman.videolan.org/pipermail/vlc-devel/2015-March/101802.html","title":"Macro/inline function and autotools"},{"location":"wiki/Porting/#guarded-time-functions-ansi-format-specifiers","text":"Some things in mingw-w64 are (maybe unexpectedly) guarded by #ifdef s. Check out _POSIX_C_SOURCE , __USE_MINGW_ANSI_STDIO , the time.h file. Note that (at the time of writing) pthread.h contains some defines that affect the definitions in time.h .","title":"Guarded time functions, ANSI format specifiers"},{"location":"wiki/Porting/#undefined-references-and-linking-to-dllssos","text":"[this section may contain misinformations; it needs review from a knowledgeable person] Linux/ELF platforms generally don't do anything special to link to shared objects, they just leave the undefined references in the binary. Windows however requires all references to be resolved at link time. In case of DLLs, this is solved by the .dll.a import libraries that add the relevant .dll to the binary's import table and insert correct calls into the code, but it needs that correct linker flags be passed when linking binaries. Note that the linker is aware of these files and will use them automatically when using the standard -l arguments, for example -lfoo will make the linker check for libfoo.dll.a and libfoo.a , in this order (unless specified otherwise). Libtool generally refuses to create DLLs unless -no-undefined is passed to the linker invocation ( library_la_LDFLAGS = -no-undefined ). See: https://lists.gnu.org/archive/html/libtool/2007-04/msg00066.html","title":"Undefined references and linking to DLLs/SOs"},{"location":"wiki/Porting/#library-prefixes","text":"mingw DLLs follow the convention of prefixing libraries with lib . This affects shared libraries ( .dll ), static object archives ( .a ), and DLL import libraries ( .dll.a ). Because msys2 DLLs are generally ABI-incompatible with everything from outside of msys2 , they are prefixed with msys2- instead. For completeness, we note that Cygwin DLLs are prefixed with cyg . [does libtool or the linker handle this automatically?]","title":"Library prefixes"},{"location":"wiki/Porting/#standard-streams-in-mintty","text":"mintty is primarily designed to be a good terminal emulator (in the POSIX sense of the word) and it works well with bash, ssh and other Cygwin/MSYS2 programs. Because native Windows console programs use a fundamentally different way of handling console input/output, mintty uses pipes to connect to their standard streams (stdin, stdout, stderr). Unfortunately, this has the effect that isatty and similar APIs (used to check whether a stream is attached to an interactive console or a pipe/file) will return incorrect values for native programs running under mintty. One way of fixing this problem is to run native programs inside a real Windows console, hide the console and use the console API to communicate with the program. This approach has obvious disadvantages, but it's good enough. Actually, this is the way most Windows console emulators work (e.g. ConsoleZ, ConEmu). There is also a wrapper program called winpty that does exactly this and translates the I/O to/from standard terminal sequences which mintty understands. Running a program under winpty (by prefixing the command line with winpty ) will make the program think it is running interactively, but it will also break any special features depending on terminal sequences, possibly including colored text output and TUIs. MSYS2 includes wrappers for some affected programs, so that they will work correctly most of the time. Examples can be seen in packages containing REPLs (python3, lua, nodejs, ...). mintty issue #56 , original on Google Code winpty on GitHub","title":"Standard streams in mintty"},{"location":"wiki/Porting/#signals-in-mintty","text":"When running a native Windows program in mintty (or urxvt, apparently), Ctrl+C will not be correctly passed to the process. Instead, it seems to be eaten by the terminal and the running process is terminated. ticket #135","title":"Signals in mintty"},{"location":"wiki/Porting/#paths-in-mingw-python","text":"The mingw python provided by MSYS2 will try to produce paths that are right for the environment it's running in. According to the value of MSYSTEM , it will use either forward or backward slashes as os.path.sep .","title":"Paths in mingw Python"},{"location":"wiki/Porting/#response-files","text":"When passing arguments with absolute paths to native Windows programs (such as /mingw64/bin/gcc ), these paths get (in most cases) automatically converted by MSYS2 if they're in POSIX format. However, if you're passing these paths inside a file (e.g. a response file for GCC -- gcc @somefile ), they need to be pre-converted to Windows native format. discussion topic: gcc -I (eye) uses msys2 path or windows path?","title":"Response files"},{"location":"wiki/Porting/#setting-floating-point-precision","text":"Floating point precision issues with multiple threads: gfortran, open mp and floating point precision by Carl Kleffner: https://sourceforge.net/p/mingw-w64/mailman/message/33332276/ https://gcc.gnu.org/wiki/FloatingPointMath https://gcc.gnu.org/wiki/x87note","title":"Setting floating point precision"},{"location":"wiki/Porting/#command-line-parsing","text":"Windows programs parse the command line themselves, it isn't parsed for them by the calling process, as on Linux. This means that if wildcards (glob patterns) are to be accepted by the program, it has to be able to expand them somehow. MinGW-w64 supplies the correct start-up code, so it happens automatically, in a manner compatible with MSVC-compiled programs. If undesirable, the behavior can be disabled at program build. Cygwin/MSYS2 programs have to deal with a mix of both approaches, but they can apparently deal with it. Note that they don't behave exactly like native programs, for example they understand single-quoted arguments. \"How Command Line Parameters Are Parsed\" by David Deley \"Everyone quotes command line arguments the wrong way\" by Daniel Colascione","title":"Command line parsing"},{"location":"wiki/Porting/#other-resources","text":"A collection of articles on general C and C++ topics. http://locklessinc.com/articles/ The MinGW-w64 project's wiki. http://sourceforge.net/p/mingw-w64/wiki2/browse_pages/","title":"Other resources"},{"location":"wiki/Setting-up-SSHd/","text":"One can apparently connect the OpenSSHd build included with Windows to MSYS2. Diablo-D3 has written down the steps here: https://github.com/Diablo-D3/dotfiles#opensshd-on-windows MSYS2 can also use its own OpenSSHd. Use the set-up script below. #!/bin/sh # # msys2-sshd-setup.sh \u2014 configure sshd on MSYS2 and run it as a Windows service # # Replaces ssh-host-config <https://github.com/openssh/openssh-portable/blob/master/contrib/cygwin/ssh-host-config> # Adapted from <https://ghc.haskell.org/trac/ghc/wiki/Building/Windows/SSHD> by Sam Hocevar <sam@hocevar.net> # Adapted from <https://gist.github.com/samhocevar/00eec26d9e9988d080ac> by David Macek # # Prerequisites: # \u2014 a 64-bit installation of MSYS2 itself: https://msys2.org # \u2014 some packages: pacman -S openssh cygrunsrv mingw-w64-x86_64-editrights # # Gotchas: # \u2014 the log file will be /var/log/msys2_sshd.log # \u2014 if you get error \u201csshd: fatal: seteuid XXX : No such device or address\u201d # in the logs, try \u201cpasswd -R\u201d (with admin privileges) # \u2014 if you get error \u201cchown(/dev/pty1, XXX, YYY) failed: Invalid argument\u201d # in the logs, make sure your account and group names are detectable (see # `id`); issues are often caused by having /etc/{passwd,group} or having # a modified /etc/nsswitch.conf # # Changelog: # 09 May 2020 \u2014 completely remove additional privileged user # 16 Apr 2020 \u2014 remove additional privileged user # \u2014 only touch /etc/{passwd,group} if they exist # 27 Jun 2019 \u2014 rename service to msys2_sshd to avoid conflicts with Windows OpenSSH # \u2014 use mkgroup.exe as suggested in the comments # \u2014 fix a problem with CRLF and grep # 24 Aug 2015 \u2014 run server with -e to redirect logs to /var/log/sshd.log # set -e # # Configuration # UNPRIV_USER = sshd # DO NOT CHANGE; this username is hardcoded in the openssh code UNPRIV_NAME = \"Privilege separation user for sshd\" EMPTY_DIR = /var/empty # # Check installation sanity # if ! /mingw64/bin/editrights -h >/dev/null ; then echo \"ERROR: Missing 'editrights'. Try: pacman -S mingw-w64-x86_64-editrights.\" exit 1 fi if ! cygrunsrv -v >/dev/null ; then echo \"ERROR: Missing 'cygrunsrv'. Try: pacman -S cygrunsrv.\" exit 1 fi if ! ssh-keygen -A ; then echo \"ERROR: Missing 'ssh-keygen'. Try: pacman -S openssh.\" exit 1 fi # # The unprivileged sshd user (for privilege separation) # add = \" $(if ! net user \" ${ UNPRIV_USER } \" >/dev/null ; then echo \"//add\" ; fi) \" if ! net user \" ${ UNPRIV_USER } \" ${ add } //fullname: \" ${ UNPRIV_NAME } \" \\ //homedir: \" $( cygpath -w ${ EMPTY_DIR } ) \" //active:no ; then echo \"ERROR: Unable to create Windows user ${ UNPRIV_USER } \" exit 1 fi # # Add or update /etc/passwd entries # if test -f /etc/passwd ; then sed -i -e '/^' \" ${ UNPRIV_USER } \" ':/d' /etc/passwd SED = '/^' \" ${ UNPRIV_USER } \" ':/s?^\\(\\([^:]*:\\)\\{5\\}\\).*?\\1' \" ${ EMPTY_DIR } \" ':/bin/false?p' mkpasswd -l -u \" ${ UNPRIV_USER } \" | sed -e 's/^[^:]*+//' | sed -ne \" ${ SED } \" \\ >> /etc/passwd mkgroup.exe -l > /etc/group fi # # Finally, register service with cygrunsrv and start it # cygrunsrv -R msys2_sshd || true cygrunsrv -I msys2_sshd -d \"MSYS2 sshd\" -p /usr/bin/sshd.exe -a \"-D -e\" -y tcpip # The SSH service should start automatically when Windows is rebooted. You can # manually restart the service by running `net stop msys2_sshd` + `net start msys2_sshd` if ! net start msys2_sshd ; then echo \"ERROR: Unable to start msys2_sshd service\" exit 1 fi","title":"Setting up SSHd"},{"location":"wiki/Signing-packages/","text":"[ rough draft ] Have a GPG key Create your new key: gpg --gen-key more... [ TBD: how strong should the key be? ] Back it up: gpg --export-secret-keys --armor <keyid> > my_key_backup.asc more... In case you need to import the backup later: gpg --import <backup_file> , gpg --edit-key <keyid> and trust it ultimately. Export the public key: gpg --export --armor <keyid> > my_pub_key.asc If you're going to use the key for GPG/MIME or share your signed packages with other people, you probably need publish your key: gpg --send-key <keyid> more... Import into pacman This is needed because pacman has its own keystore and own rules for trusting keys. Either you get approved as a packager for the MSYS2 project, or you have to import your key manually. To import and sign your key with pacman-key : pacman-key --add <pubkeyfile> , or if it's published pacman-key --recv-keys <keyid> pacman-key --lsign-key <keyid> more... To make your key a trusted developer key for signing official packages, you have to get your key included in the respective keyring and get it signed by at least 3 master keys. The package and repository is msys2-keyring for MSYS2, see Alexpux/msys2-keyring . The package and repository for Arch Linux is archlinux-keyring , see https://projects.archlinux.org/archlinux-keyring.git/ . These packages install keyring files into /usr/share/pacman/keyrings which then can be imported and locally signed in one batch using pacman-key --populate <keyringname> . Actually sign stuff Old packages: gpg --detach-sign --no-armor <pkg> for each package (all such packages need to be re- repo-add ed to make the database aware of the new signatures) New packages: just add --sign to makepkg command line or set the related makepkg.conf option Databases: repo-add -s -v <db> <pkg>","title":"Signing Packages"},{"location":"wiki/Signing-packages/#have-a-gpg-key","text":"Create your new key: gpg --gen-key more... [ TBD: how strong should the key be? ] Back it up: gpg --export-secret-keys --armor <keyid> > my_key_backup.asc more... In case you need to import the backup later: gpg --import <backup_file> , gpg --edit-key <keyid> and trust it ultimately. Export the public key: gpg --export --armor <keyid> > my_pub_key.asc If you're going to use the key for GPG/MIME or share your signed packages with other people, you probably need publish your key: gpg --send-key <keyid> more...","title":"Have a GPG key"},{"location":"wiki/Signing-packages/#import-into-pacman","text":"This is needed because pacman has its own keystore and own rules for trusting keys. Either you get approved as a packager for the MSYS2 project, or you have to import your key manually. To import and sign your key with pacman-key : pacman-key --add <pubkeyfile> , or if it's published pacman-key --recv-keys <keyid> pacman-key --lsign-key <keyid> more... To make your key a trusted developer key for signing official packages, you have to get your key included in the respective keyring and get it signed by at least 3 master keys. The package and repository is msys2-keyring for MSYS2, see Alexpux/msys2-keyring . The package and repository for Arch Linux is archlinux-keyring , see https://projects.archlinux.org/archlinux-keyring.git/ . These packages install keyring files into /usr/share/pacman/keyrings which then can be imported and locally signed in one batch using pacman-key --populate <keyringname> .","title":"Import into pacman"},{"location":"wiki/Signing-packages/#actually-sign-stuff","text":"Old packages: gpg --detach-sign --no-armor <pkg> for each package (all such packages need to be re- repo-add ed to make the database aware of the new signatures) New packages: just add --sign to makepkg command line or set the related makepkg.conf option Databases: repo-add -s -v <db> <pkg>","title":"Actually sign stuff"},{"location":"wiki/Sudo/","text":"Do you need Sudo? In regular GNU/Linux environments, people use sudo to perform administrative tasks on their system, e.g. installing and removing packages, editing system configuration. Since the most common way of installing MSYS2 results in the MSYS2 root directory being writable by the user, these tasks can be performed without doing anything special. If you made your MSYS2 root read only for users or want to run Windows administrative tasks from MSYS2, continue reading. How to get Sudo Since MSYS2 doesn't support all the things a classic Sudo needs (setuid? PAM?), we need a replacement. One such replacement that doesn't seem to suffer from horrible security flaws is win-sudo . It doesn't support (as of May 2020) the various different arguments ( -H , -u etc.), but it does work in the most common use case of sudo foo running foo with elevated privileges. The authorization is handled by UAC, same as any other Windows program.","title":"Do you need Sudo?"},{"location":"wiki/Sudo/#do-you-need-sudo","text":"In regular GNU/Linux environments, people use sudo to perform administrative tasks on their system, e.g. installing and removing packages, editing system configuration. Since the most common way of installing MSYS2 results in the MSYS2 root directory being writable by the user, these tasks can be performed without doing anything special. If you made your MSYS2 root read only for users or want to run Windows administrative tasks from MSYS2, continue reading.","title":"Do you need Sudo?"},{"location":"wiki/Sudo/#how-to-get-sudo","text":"Since MSYS2 doesn't support all the things a classic Sudo needs (setuid? PAM?), we need a replacement. One such replacement that doesn't seem to suffer from horrible security flaws is win-sudo . It doesn't support (as of May 2020) the various different arguments ( -H , -u etc.), but it does work in the most common use case of sudo foo running foo with elevated privileges. The authorization is handled by UAC, same as any other Windows program.","title":"How to get Sudo"},{"location":"wiki/Terminals/","text":"This is a basic explanation of how console programs work in Cygwin and MSYS2. GUI (graphical, windowed) programs fall outside of the scope of this text. Note that this topic is not simple and there are many factors that can cause differences in observed behavior ( TERM , LANG , LC_* ...). The following information is our best understanding and our best attempt at explaining it. If the reader has any corrections or clarifications, please post to the mailing list. Note that where we say MSYS2 below, it usually denotes Cygwin as well. MSYS2 (more generally POSIX) and regular Windows (i.e. non-MSYS2 ones) console programs both use character streams to read data from the user and to display data to the user. If reading and writing simple text is the only thing a program does (i.e. it's not interactive), then the program's I/O should be easily portable between Windows, MSYS2 and other platforms. On a more advanced level, e.g. when a program employs a REPL or uses colored output or draws TUIs , the two systems are fundamentally different. MSYS2/POSIX programs use in-band terminal sequences , while Windows programs use out-of-band calls to the Windows Console API . In the POSIX world, REPLs are often programmed using the readline library and TUIs using the ncurses library. Terminals Terminals are programs that interface with console programs and facilitate their input (e.g. accept keypresses from the user and send corresponding characters to the program) and output (e.g. draw the characters from the programs as corresponding glyphs on the screen). Mintty is a terminal emulator built for MSYS2 programs. It provides the necessary POSIX interfaces to MSYS2 programs. There are other terminal emulators in Cygwin, but they're not provided in MSYS2. The Windows console ( conhost ) does the same for Windows programs. It provides the back-end to the Windows Console API. Shells A distinct category of programs are shells . A shell is the actual program that reads commands from the user and runs them. The \"DOS window\" in Windows is actually a combination of a Windows console and the Windows shell ( cmd , command line). Likewise, when you open a mintty window, you'll probably see the bash shell running inside and waiting for your commands. This matching is not mandatory though, as bash can be run in a Windows console and cmd can be run in mintty. Mixing MSYS2 and Windows MSYS2 allows some inter-operation between a MSYS2 program and Windows console and between a Windows program and MSYS2 terminal emulators. For basic stuff, it works fine. Anything more complicated, like colored text, TUIs and line editing , is a lottery -- it can work, it can break. Winpty is a wrapper program that works as a translator between Windows programs and MSYS2 terminals. It opens an invisible Windows console window and runs the wrapped program in it. It then relays input from the terminal to the program and output from the program to the terminal. This solves a lot of the issues of running Windows programs in a MSYS2 terminal.","title":"Terminals"},{"location":"wiki/Terminals/#terminals","text":"Terminals are programs that interface with console programs and facilitate their input (e.g. accept keypresses from the user and send corresponding characters to the program) and output (e.g. draw the characters from the programs as corresponding glyphs on the screen). Mintty is a terminal emulator built for MSYS2 programs. It provides the necessary POSIX interfaces to MSYS2 programs. There are other terminal emulators in Cygwin, but they're not provided in MSYS2. The Windows console ( conhost ) does the same for Windows programs. It provides the back-end to the Windows Console API.","title":"Terminals"},{"location":"wiki/Terminals/#shells","text":"A distinct category of programs are shells . A shell is the actual program that reads commands from the user and runs them. The \"DOS window\" in Windows is actually a combination of a Windows console and the Windows shell ( cmd , command line). Likewise, when you open a mintty window, you'll probably see the bash shell running inside and waiting for your commands. This matching is not mandatory though, as bash can be run in a Windows console and cmd can be run in mintty.","title":"Shells"},{"location":"wiki/Terminals/#mixing-msys2-and-windows","text":"MSYS2 allows some inter-operation between a MSYS2 program and Windows console and between a Windows program and MSYS2 terminal emulators. For basic stuff, it works fine. Anything more complicated, like colored text, TUIs and line editing , is a lottery -- it can work, it can break. Winpty is a wrapper program that works as a translator between Windows programs and MSYS2 terminals. It opens an invisible Windows console window and runs the wrapped program in it. It then relays input from the terminal to the program and output from the program to the terminal. This solves a lot of the issues of running Windows programs in a MSYS2 terminal.","title":"Mixing MSYS2 and Windows"},{"location":"wiki/Using-packages/","text":"Move to here","title":"Package Management"}]}